Re: [Ledger-smb-devel] Writing code for master: paradigms that work
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
Re: [Ledger-smb-devel] Writing code for master: paradigms that work
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 http://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.
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
* 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 ...
* 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.
As part of the frame-less change, I've addressed a long standing
irritation of mine: the handling of errors. Before, every time you
entered a form's data incorrectly, you'd be shown an ERROR page, but
not be given back the data you entered. Now, if the server reports an
error, it's shown as a popup dialog. Because of this handling, the
entered values now don't get lost. If processing fails, the scripts
should therefore make sure to return an http error to the client (with
a meaningful description in the (HTML) body).
+1
Yes. Absolutely.
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
[Ledger-smb-devel] Writing code for master: paradigms that work
Hi,
Today, Chris and I worked on merging my 'master-fixup' branch to master,
followed by the actual merge. While working on 'master-fixup', I learned a
few things that I'm summarizing here because they're really important to
know when you're developing for our 1.5+ releases. I'm thinking of creating
a page documenting these items on ledgersmb.org as well.
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
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
* Create widgets which - as much as possible - can be reused on other pages
* 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'
* 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
As part of the frame-less change, I've addressed a long standing irritation
of mine: the handling of errors. Before, every time you entered a form's
data incorrectly, you'd be shown an ERROR page, but not be given back the
data you entered. Now, if the server reports an error, it's shown as a
popup dialog. Because of this handling, the entered values now don't get
lost. If processing fails, the scripts should therefore make sure to return
an http error to the client (with a meaningful description in the (HTML)
body).
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.
Comments very welcome! I'll see how to make sections in a coding
standards document/page for publication on ledgersmb.org.
--
Bye,
Erik.
http://efficito.com -- Hosted accounting and ERP.
Robust and Flexible. No vendor lock-in.
--
___
Ledger-smb-devel mailing list
Ledger-smb-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
