Great stuff, love to hear you're tackling these issues head-on. I'm totally in favor of everything I've read from your 3 mails of today... and will add comments from my perspective...
On 06/21/2015 01:04 PM, Erik Huelsmann wrote:
It's great to organize CSS/JS to work per screen/page. However, it's not that useful to load it per page. For the most part, I think it's best to simply aggregate all the JS/CSS and send out as a single file to the browser, and allow that to get cached.
With Dojo, we can define multiple layers in the build, so it might be good to exclude seldom-used scripts to their own layer, or exclude them from the build entirely -- as long as we're using AMD Dojo should handle loading them if necessary if they're not in the build. But aggregating everything should work well for us.
Pub/Sub I've found to be extremely powerful for a single-page app, and is exactly what I've used in the past. +1
Break this out into the SASS discussion -- I'm partial to partials ...
I don't see any benefit to not loading all CSS for the app one time, in a single file. Organize all the CSS into separate Sass files per page, but in the end they all end up in a single CSS file.
And yes, a class attribute attached to the body tag can be a great way to provide per-page css, make it easy to target.
Ok. If that's the architecture we're using, I agree it certainly needs improvement.
What I've done in the past is something much like this -- providing a Request and a Response object that gets passed through the controller.
E.g. at the start of the request handling, the parameters/body is extracted and had a single controller function to figure out who handles this request. Before handing off, it gets a generic response object, with a class that is selected based on what the requestor asked for -- HTML, JSON, XML, CSV. These all are different response classes that inherit from a base response class with common methods for populating data.
Drupal 8 has moved to Symfony at its core, and the heart of Symfony is a router system and a service container. The service container basically registers a bunch of objects to handle any service. The router determines which controller to invoke. Any code along the way can request a service from the container, and at the point it's requested, that's when it's instantiated.
So... the patterns we're discussing I'm seeing put in widespread use. I'd say those 3 things are crucial for us to define/decide how we're going to implement (and perhaps find some Perl framework to assist if those we're currently using are insufficient):
* Request routing
* Service container to make it easy to register and load services
* Response object (which needs to include the definition of how to return exceptions).
Will respond to the other two posts, too...
------------------------------------------------------------------------------ Monitor 25 network devices or servers for free with OpManager! OpManager is web-based network management software that monitors network devices and physical & virtual servers, alerts via email & sms for fault. Monitor 25 devices for free with no restriction. Download now http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________ Ledger-smb-devel mailing list ..hidden.. https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel