Design Question

Permalink
Hello, I am a java programmer (I understand PHP pretty well even though I haven't worked with it), and this is my first time using Concrete5.
We have an Intranet site built with Concrete5 from someone who has left. It already has a theme created, and all of the screens are in place. It is connected to a MySQL database.
My task is to create a handful of new screens that interact with the database, such as: screen to list all stores, screen to add/edit store info, screen to list all customers (depending on filter selected by user), screen to add/edit customer info.
It looks like I could create single pages for each of these and add custom programming for each file?
But my question is this: these screens will share much of the same look-and-feel with one another ... so where should I add the PHP code for the best design? Should/could I put the code in custom blocks and then add them to these screens? (I'll have two basic page types)
Any help would be appreciated, thanks.

 
JohntheFish replied on at Permalink Best Answer Reply
JohntheFish
Elements are usually a good way of sharing custom display code between single pages. Elements are effectively includes with some scope/parameter passing.

Or for widget like diplay things, they often map more easily into helpers. For more complex things that are a bit big for a helper, a library can make sense. For the common data between the pages, use a model. All 3 of these are php classes.

Blocks become useful when you want to show something (either same data or different data) in multiple places. They can also be quick to prepare using the designer content addon.
brian1 replied on at Permalink Reply
Hello John,

Thank you for your reply. These pages are front-end screens (for any user to view). The data will be pulled from the MySQL database where new tables have been created for these screens.
I will also review the Concrete book that you recommended.

Thanks.
Brian
JohntheFish replied on at Permalink Reply
JohntheFish
If the pages are 'display only', then you could create new block types for each display, possibly using designer content, possibly starting from another block or from scratch, to get the data and show it in a table that you can then place on any regular page.

There are also some table blocks that may be able to display your tables or be easily hacked to do so. I have not done so, but a quick search on 'table' in the marketplace gives:
http://www.concrete5.org/marketplace/addons/tables/...
http://www.concrete5.org/marketplace/addons/csv-displayer/...
as a possible starting points.

If you have users entering data, you could look at using the forms block (or one of the forms derivatives), with a custom coded handler to take the entered data, validate it, and add it to your tables.

You may find a combination of 2 such blocks solve your requirement.

If it is more complex and needs a single page, for each single page you will need to code a controller and a view (you can get by with just one of these, but I find matching controllers and views 1:1 is neater, even when one is trivial). These are php files that need to live at the correct paths under /controllers/ and /single_pages/ (which you then need to declare as single pages through the dashboard or package them up and do it in the package controller - which is my preference)

C5 will then insert the output of the view into a page that has other content, headers, footers etc as per the view.php of your theme. Your single page output will be placed where the theme has
<?php  print $innerContent; ?>

Have a look at concrete/themes/greek_yogurt/view.php to see this in context.

The associated controller can set up data for the view to display and respond to form submissions from the view.

I don't know of any examples of single pages for the front end that are free downloads from the marketplace. But there are plenty of examples of free marketplace pages that add single pages to the dashboard.

The thing about dashboard pages is there are some conventions they follow for forms, headers and buttons that make them more complex than a front end single page. You need to make sure that code relating to the dashboard does not lead your front end design astray.
brian1 replied on at Permalink Reply
That was tremendously helpful information. Thanks John.