Symphony.

I just wrote an article about saving time, increasing productivity and code quality with Symphony:

Symphony is great. Let's make it better.

This article is about the process of building your website's frontend, keeping templates DRY, relating Datasources, Events and other Resources to your Pages, code structure and much more. The following haven arisen, in time, from finding myself repeating the same things over and over again.

Continue reading on GitHub.

If you find the idea interesting, post in this thread to support it and urge me to publish the implementation.

NB: There's an ensemble available containing some examples of the workflow. See the Readme for details.

I think I like the idea of this at first sight, although I may not be aware of the way it might impact on other areas of Symphony.

In fact I sometimes have a bit of confusion about what pages are exactly. I sometimes create a page and it becomes part of a site directly, maybe a simple contact page. It's ok to use navigation.xsl to access it or build navigation.

But, sometimes I find myself creating pages that are 'hidden' and not included in navigation.xsl in the traditional way, I have to build some other variant of navigation to access them. Perhaps they're in the form of a template for a bunch of 'pages' as seen on the front end. Sometimes an entire site is composed of such things.

That's OK, Symphony lets me do either or both, but, it's always seemed a little strange to have this duality. Maybe vladG is resolving this by giving my strange template/page/hidden things a place of their own in the form of his proposed widgets.

So it looks good to me, but I'm interested to hear about the deeper implications of this from others. I can't help thinking there must be a reason why things weren't always this way.

I do find the idea interesting as a way to keep code modular and maintainable and the workflow DRY. I would love to see your implementation.

@munki

I can't help thinking there must be a reason why things weren't always this way.

Well, as far as I remember, the official Symphony position was this: never make assumptions on what resides in frontend. And this is a very good thing. But ... :) there are some patterns and good practices that arise from pure needs. These needes pushed me to implement the above.

@vladG

Evolution then.

Are you using an extension to attach data sources & events to your Widgets? Also, there doesn't seem to be a Resources repository.

I like this thinking.

@lewis

Are you using an extension to attach data sources & events to your Widgets?

About 7 or 8 extensions actually. Everything is treated as a Resource. Pages, Datasources, Events, Widgets, CSS, JS, Extensions, Sections.

Since everything is abstracted to a Resource, creating relations between these Resources is as simple as saying: Page X includes Widget Y.

What are the specific extensions you are using to accomplish this workflow?

What are the specific extensions you are using to accomplish this workflow?

None that is already published. This is custom stuff, experimental, >= PHP 5.3, not unit tested etc :) but it does it's job.

After publishing I hope some more advanced users will help with some Unit testing, performance measurements etc. I don't know how to do these.

Got it.

Interesting points, I could see times when having stuff like this can speed up considerably.

What I was about to do is actually package an ensamble with the most common bits that I use, and was considering SCSS for styling so basically colours could be changed on the fly if required. with less CSS having to be written between websites. The structure you came up with is very interesting however.

Forgot to write something essential in the article:

Have I told you that a Widget can be linked to another Widget? Yes, they can be linked. So, the final solution to our problem would be:

1. Create Master widget
2. Create Next event widget
3. Home & Contact pages already include Master
4. Link Master to Next event

Ta-da !

P: Home -> W: Master -> W: Next Event -> DS: Next event

@vladG: getting your code unit tested is pretty much impossible right now. The reason for this is the very tight dependencies you will get if you need to access the Symphony API (unfortunately).

Me and Jens are currently working on rewriting the database layer to include performance tuning in the ASDC extension, and we will be unit testing this. From there on we plan on slowly rewriting the core components to make unit testing a whole lot easier (read: make it possible).

This however, is quite a big task, and it will probably take a while before the entire core (and thus extensions) are testable.

Oh, and: why do you create a single css and js file for each page? I tend to compress them, and merge them all in one file to use browser caching. This is because I rather transmit 1 slightly larger file (lots of css and JS can be reused between pages) than multiple smaller ones.

@creativedutchmen

Merging all CSS files together in one minified CSS file is part of the deployment process. This is the developer's responsability on deploying production version. The above methodology applies to development process and allows splitting functionalities in integrated DRY chunks, nothing more. Want to minify & compress assets? No problem, but that's another challenge to tackle.

Depending on a variable (== 'dev' or == 'prod' etc), one can load the production CSS file, or each separate CSS file from Pages & Widgets.

@vladG: So does your (single?) production CSS file include all of the widget CSS files? And likewise for the JS file/files?

Have you looked into Nils' XSL Resource Loader-extension? Could help creating a similar workflow without making things too complex or restricted to a specific structure.

@DavidOliver:

Yes, they will. ATM I didn't set up my deployment process that far, but that's the goal.

@jensscherbl

IMO, XSL code & stylesheets should restrict to processing XML, not providing configuration as well. In Nils' extension I noticed the delegates for Datasources & Events and come up with this idea where configuration is scalable and is stored in fellow XML files.

OK ... Sorry for being sooo late. I've been terribly busy until holidays and now I'm back from vacation.

I uploaded a Symphony 2.3.1 ensemble that bundles the Resources. Install as usual and make sure you check out the code starting from Home page. The main thing was adding a Newsletter widget on all pages.

Read le Readme.

I'll publish each Resources_* extension separately when I have more spare time. For the moment, I recommend testing things on this working ensemble.

VladG the resources and article links in the 2.3.1 link above are missing a 't' in the github URI... it takes us to gihub.com ;)