Hi John,
On Mon, Jun 22, 2015 at 7:03 AM, John Locke <m...@freelock.com> wrote:
> Hi, Erik,
>
> 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:
>
> What I learned while coding on current master, i.e. after the
> 'frame-less' and 'PGObject' changes, is that, due to the 'frame-less'
> change:
> * The HTML HEAD tag is now completely useless, except for the pages
> returned by 'login.pl'
> * Any JS linked in the head tag as well as any JS included in SCRIPT tags
> is completely ignored
> * Any CSS linked in the head tag is completely ignored
> * Any JS or CSS directly included in the head tag is completely ignored
>
> 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.
>
While I agree with you that aggregation would work well for us (and
there's very little to be aggregated at the moment, because we have very
little code in our own classes!), having aggregated JS files is somewhat of
a problem from where we stand today: we don't have a build system, so we
don't have something to hook the aggregation dojo build step into...
Actually, with the very little code that we have now, I'm actually
expecting that there's not too much benefit in terms of speed of building
our own aggregated Dojo, if we depend on the dojo version people can load
from the CDNs or as available in the distributions. That eliminates most
roundtrips already.
> What *does* work is:
> * Put all behaviours for all elements in Dojo widgets
> * Put nothing in the response HTML other than widget references
> (data-dojo-type) and widget configuration (data-dojo-props); everything
> else should be in the widget
> * In case widgets on a page need to communicate their state changes, etc,
> use 'dojo.topic' and the publish/subscribe paradigm -- this creates a
> loosely coupled UI and reduces chances for exceptions
>
> 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
>
> * Create widgets which - as much as possible - can be reused on other
> pages
>
> +1
>
Ok. Thanks for seeing those items confirmed. I'll need to write that down
into a page about our coding standards on ledgersmb.org.
> * Make sure the HTML structure is valid; the Dojo AMD parser can be
> seriously confused by incorrectly nested elements
> * All CSS for any and all pages must be included in 'css/global.css'
>
> Break this out into the SASS discussion -- I'm partial to partials ...
>
Ok. I think we're on the same page: the end result must all be in CSS
that's loaded when the single-page-app's single page is loaded. If this is
done in partials which are then included into a larger single file which
can be generated using a build step, that's open for discussion. (But it
suffers from the same problem as the one mentioned above: there's no build
at the moment, so there's nothing to hook this into...
* CSS can be made page-specific by wrapping the entire body of an HTML
> response's BODY tag in a DIV with a page-specific (and globally unique) ID
> attribute; that attribute can be used to attach the page's CSS to
>
> 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.
>
We're on the same page here. Your words say exactly the same thing I meant
to say.
[ snip ]
> Due to the PGObject change, it has become clear - if that wasn't already
> the case - that our current handling of the $request variable is far from
> ideal. Problems that we have:
>
> * $request is manipulated into a response by replacing values in the
> hash as processing proceeds (leading to a point that code can't be sure
> what values it's receiving!)
> * some parts of the code instantiate new hashes, expecting constructors
> to copy *everything* of $request which they are not providing themselves
>
> Even though dojo-ifying the entire code base (by which I mean that we
> will be transforming everything to dojo UI and service requests from there)
> -- and thus we'll be moving away from the template based processing
> structure -- I think it's important to lay out how this should work as the
> move to PGObject caused problems in this respect.
>
> The problems with PGObject and the $request object being mutilated into
> a response object (or being replaced by another object) are most apparent
> in relation to the template processing engine when values aren't copied
> from $request to its replacement.
>
> Basically, my view on things is that there shouldn't be a replacement at
> all. Instead, $request should hold all the values as passed in by the
> request. $request should *always* be passed into the template engine in the
> { request => $request } variable, so templates can refer to the original
> values. These values include - most importantly - the name of the script
> from which the template is being called: request.script (this is required
> for correct form submission, most of the time).
>
> In addition to the $request object, one or more objects can be and
> should be passed in from which the template engine should generate the
> response. This is a lot like the handling of the contact screen already
> takes place (but in many places in the code it doesn't).
>
> Why write it down if we're going to move away from it anyway? Well,
> because if smaller problems need to get fixed in those areas, rewriting to
> this paradigm might actually already fix the issues encountered.
>
>
> 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).
>
>
Thanks for these, I think we'll need to integrate these points into the
discussion that spins from Chris's response in the other thread about being
able to use exception processing and possibly rerouting response handling
based on the exception being thrown (although I think that using exceptions
is an implementation detail to the requirement of being able to reroute a
request to a different service/route).
Thanks for taking the time to respond!
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
------------------------------------------------------------------------------
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
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
