(warning: long post)
This post is directed towards anyone considering design aspects of Mozilla's layout/XPFE technology.
I've just completed a large Mozilla tutorial & reference documentation project, which I leave to others to shamelessly plug. One outcome of that work is a solid view of some of the obstacles that newbies face in layout/XPFE when learning Mozilla technology.
I originally posted these remarks as comment 19 to bug 184746, but they are too broad for that bug alone, so I put them here for discussion before considering which should have bugs.
Please understand that my view is that popularity of Mozilla depends in part on the ease of learning it. That, I would have thought, is a no-brainer motherhood statement for pretty much any piece of technology. But ease of learning constrains what should and shouldn't be implemented, which is always up fo debate.
To summarise, my comment (below) asked Mozilla:
A: divide exposed features of layout (CSS?) into "programmer available" and "unavailable".
B: keep the idea of a frame because its easy for learners.
C: make some rules to ensure frames/widgets are implemented with a degree of uniformity in the DOM/XPCOM.
D: provide a special frame that programmers can learn on.
E: rename command "controllers" so that controller is strictly used as a MVC (Model-View-Controller) term, and not also as a Command pattern implementation term.
F: treat XPFE JS programmers as first class users of the layout engine in terms of priorities.
Within the context of bug 184746 (with typos fixed) I put this:
(begin comment)
I ask the contributors here to add some further thoughts for the users of your works when considering future changes to the layout engine. I speak as a technical communicator who must translate your decisions into conceptual material that is at minimum comprehensible, but that ideally is also conceptually clean.
[ .. chop .. ]
In particular I'm speaking for non-embedded(XPFE) learner programmers, who occassionally are exposed to: frame and frame-like artifacts of the layout engine, artifacts related to the Model-View-Controller pattern, and the extensions to that pattern (builders, renderers, etc) that are required for a full implementation. It is my job, or part therof, to make a serious attempt at easing the burden of learning these concepts. One way to do that is to encourage you to make those concepts non-burdensome in the first place.
In the current design (and I accept that exploiters of the layout engine may be more responsible than designers of that engine), some aspects of layout are quite confusing to beginners/learners. One sentence of truisms: no programmer successfully enters the Mozilla diaspora without learning; and Mozilla technology benefits the most from well-informed programmers.
The first confusing aspect is that of (my terminology) extrinsic versus intrinsic layout elements. The property pattern used to specify layout properties (in CSS) is a flat hierarchy, and it is non-obvious which of these properties are of interest to XUL/CSS/JS programmers, and which are implementation details handily exposed. A big ask to you all is to (A) somehow taxonomically group exposed parts of the layout engine into "those bits XPFE programmers might conceivably use" and "those bits that should stay buried".
For learners, we once had some grouping of this nature with pseudo-classes, which look at intrinsic aspects of the layout (eg :first-letter digs into a block/box constructed from more than one layout primitive), but various -moz enhancements now also grant access to intrinsic-like aspects of the layout, so the line is blurred. Could there be some grouping of those intrinsic elements?
On top of all that, learners need an entry-level concept to cling to, and that concept is currently the "frame". So another big ask is to (B) constrain your re-architecting so that the concept of frame retains some approximately correct meaning for learners.
Regardless of whether you believe that frames/MVC are discrete concepts or not, and regardless of whether they are discrete from the nitty-gritty of implementation, the pragmatic fact is that they are early rocks that learners will cling to when attempting to access the technology. Anything that gives that early clinging action validity in future problem solving is good.
For example, should a frame become factored into two or more pieces, those pieces taken as a lump and used crudely should still have some currency as a frame (or as some new noun, but frame is the lingua franca and I vote it is retained). Once programmers gain experience with frames they can go from confident/part-right to confident/accurate. Without a frame concept, they must go from uncertain/unknown to confident/accurate directly. That latter transition is common for gifted thinkers, but the former is easier for the majority. Please retain the concept of a frame, even if it is retained in a somewhat abstract form.
A second confusing aspect is that of value-added uses of the layout (kick me if I'm OT). In particular, layout builders, views and controllers are exposed to XPFE programmers very patchily. It is not obvious that every significant XML tag (say) has MVC status, since only <menupopup>, <listbox>, <tree> and <template> expose anything to the DOM/XPCOM of the internals, and only <tree> makes an attempt at exposing a reasonable part of the pipework.
No one is saying the current layout engine has shortcomings, it is just that this limited exposure of MVC plumbing poses significant problems to learners. It means that the big, ugly tags (<tree>, <template>) are loaded with learning hurdles separate and in addition to their base conceptual use. Trees are confidence defeating, because they are conflated with MVC concepts not yet seen elsewhere in the XUL widget (or frame) set.
No one would advocate padding out the layout engine so that the M,V,C,builder, renderer, etc of each tag is exposed via the DOM/XPCOM. For consistency, however, some uniformity is required if the functionality of the design is to make rational sense. A big ask to you all is to (C) make some rules about this exposure that will apply to ALL DOM/XPCOMed tags, and then reduce away most of the complexity everywhere except where necessary.
If that means contructing layout APIs that encourage uniform design for specific XML rendering systems (HTML, XUL), then so be it.
The first corollory to this last point is that there should be a demo frame (and suitable tag) that learners can use as a test-bed before they attack the <tree> tag or templates. That frame should be exercisable so that the programmer can control the layout *process* in code, thus revealing the dynamics of the engine, and preparing the way for more complex uses. Such a beginner's sample is common to most development environments, and in Mozilla would go a long way to helping the user understand MVC, renderers and builders. That is big ask (D). You may well point me towards <iframe> or similar, but of course, the layout process is conflated with document management concepts in that case. <iframe> is not a simple learning testbed.
The second corollary is that of interface-object relationships. To an XPFE JS programmer, it is not currently clear (or at least not as clear as it might be) what the relationships are between various concepts. It is a quagmire for the learner. On the one hand, there is the theory of MVC. This theory does not map 1-1 (or neatly) to the architectural concepts of builders, renderers or (sigh, [command] controllers). Then there is the matter of underlying, possily XPCOM'ed, objects. Neither theory or architecture map neatly to those objects. Just listen to anyone frothing at the mouth trying to differentiate the content builder from the template or tree builder, or trying to understand why a tree-and-template combination uses the tree builder not the template builder, when a box-and-template combination uses the template builder (from my poor memory, which just shows the point).
Again, it is unfair to land this problem strictly on layout, but layout provides the primitives that these higher systems (except for the controllers, sigh) are at least partially built out of.
Great as it currently is, "controller" as jargon should be bought back
by layout. The Command pattern underlying the controllers in the DOM
should provide an alternate property name that better reflects command
jargon (eg "commandFacades"). If MVC is to be a useful crutch for
learners, then controllers should appear in the layout jargon/implementation only. That is big ask (E).
Here is a simple example of the cognitive disharmony that can result from mis-matched theory vs implementation. Look at the filesystem directory XPCOM objects, which I hope you are unfamiliar with. To explain this little system, one must explain the theory (providers are registered with queried directory services), and then match it to the technology:
@mozilla.org/file/directory_service;1 and friends
All is well, until, dismayingly, this XPCOM object also contains a provider, one that is used directly and not via a service it is to be registerd with. This exception is digestable once pointed out but not easily discoverable. It is also at the expense of the initially described model, which is now either useless or distractingly special-cased, depending on your point of view.
Alas, the layout system combined with the various semi-exposed objects is far more special-cased than the filesystem services.
In summary, this note is a request that you appreciate that one measure of a successful re-architecture is the maximum ply of the implied learning path.
Laying out a tag like <DIV> or <box> is a one-ply (one step) learning path, well supported by Mozilla. <UL> is a two-ply learning path, because both <UL> and <LI> must be comprehended before virtuosity is achieved. The more complex parts of the layout process: lists, trees, and templates, have very high plys currently, and are obstacles to the gaining of that sense of virtuosity. And yet trees and templates are almost mandatory tech for XPFE folk.
No doubt the layout engine should be able to silently and seamlessly solve the display of a given XML document using nothing but content and CSS hints, but in practical terms programmer will interact with it more than that.
My biggest ask, therefore, is (F) that XPFE (application, JS) programmers be put abreast of embedded C/C++ programmers. In the long term they will be more numerous and on average less gifted than the embedders, since most software is application software. Perhaps they will never be as numerous as Web developers, but they are more likely to aid this community. Please add their learning needs to your considerations.
(end comment)
regards, Nigel.
_______________________________________________ Mozilla-layout mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-layout
