Move your JS to the bottom of the body tag. Let the rest of the page load while the JS is downloading. Not a huge deal, but you will see slight performance improvements. That's not really within the scope of separation of concerns per se, just something I noticed.

I have 3 ideas I am working on at the moment.a. Delivery Manager for local shops (ie bakeries, liquor stores etc)b. Checklist Manager for companies that require checklists to be filled in on completion of work. (eg cleaning service) with different checksheets for different clients.c. Mechanics , simple jobcard system for backyard mechanics.

But I don't want to push any of my ideas forward as I am more interested in learning processes than getting someone to help me write software.

Almost all systems I have been involved in have a user login page with the default registrations, password resets and logins etc.That would be the most logical place to start i think.

I will do a css style sheet and post tomorrow for the basic site layout.Is it better to use something like bootstrap for this or solid css?

I think you are getting a little ahead of what we can do here. Both from the practical sense of not being able to handle a lot of design/development in a forum thread, and in the Agile/XP sends of not knowing what we are implementing. The positive statement of YAGNI is to only implement what you really know what you what and how to do it. We don't need to style a form until we have a working form to style.

I think we should implement a forms manager that will handle the needs of the forms you present above. So we need to be able to create and update things like deliveries, checklists, jobcards or logins. Before you start on the stylesheet, let's determine what the requirements of this forms manager first. That is a finite project that we can do in this thread. With it you should be able to create any of the forms above and style them any way you want. But once we get the forms manager done, we will know more and we can then decide what the next most important project is.

So can you come up with a list requirements common to all the forms above?

I must be honest, I am still not sure what you mean by a forms manager.

The above are separate ideas so they cannot be taken as a whole.If I had to tackle one of them lets say an app where people can create test for anyone to take or maybe their companies training room to use.

I guess I was thinking of a further step back to the basic functioning of this page. All you showed in your previous post was really the template code (i.e., the Presentation or View). But I suspect that the code that controls this form and the code that talks to your database have similar problems. Ultimately this is all about the data. That data comes from somewhere and it ends up somewhere. In between the data is presented and managed by something. Your list was everything but the application architecture.

For example just before your last post, another member posted form code with a question about redirecting on success. Redirecting on success happens to be a Best Practice to eliminate the problem of having a form submitted multiple times. The code (viewtopic.php?p=703671#p703671) handles everything about the form in a single PHP script. Obviously much simpler that yours. So what do you think about Separation of Concerns in that person's code?

Not just that, because the Presentation side (i.e., the PHP generated HTML and Javascript/CSS that enhances the HTML) is important and where your question started. But since the original review was about Separation of Concerns, I think it makes sense to start with a blank slate and build up to the Presentation part -- which for me comes last. Also, if we build up code that anyone can run, then people can follow along.

So my statement above about Presentation part coming last might be a place to start. Obviously we need to define Concerns before we can separate them. And as we discussed earlier, Concerns are not all equal. There are reasons of both dependency and practice that determine the order you might build things.

The whole reason for the apps you list above is to deal with some data. Whether it is deliveries, checklists, jobcards or user accounts, all of the apps you listed are based on reading and writing data. So typically you start with the Domain or Model when designing. So maybe pick one of the apps you listed and define what the data is.

Who is online

Users browsing this forum: No registered users and 3 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum