Re: [Echo-list] EchoXUL Framework Preview Release

[<tj...@la...>]

Domagoj,
Thank you for your comments.  I would second your motion to not start a
fight over "XUL is bad / XUL is great".

First, I would like to clarify my intentions regarding this effort.  I
am not trying to supplant anything that has been done.  Personally, I
don't care whether EchoXUL stays around, gets merged, or gets dropped
completely... so long as something of the ideas in it permeate the Echo
community and ultimately lead to enhancements to Echo.  That is why I
commissioned it as a separate project.  I wanted to be able to incubate
some ideas in an isolated corner of the Echo universe without having to
worry up front where they fit.

In fact, this effort came about out of some prolonged experimentation
that I did with HTMLTemplatePanel and JSPTemplatePanel.  At the time, I
had written several extensions to those classes and exchanged emails
with Brad Baker regarding them.  I believe that some of these ideas and
fixes were included in the last Echopoint release.  I really liked
working with Brad and I have the utmost respect for him, but I just had
this itch that things could be different -- so I set off to see what I
could come up with.

Basically, I had this idea that I wanted to experiment with an XML
based layout system.  I took a revived look at XUL and realized that at
least many of the ideas present there were directly applicable to what
I was trying to do.  Stock XUL recognizes two namespaces (not counting
RDF and everything required to set up events, etc): XHTML and XUL.  Since
Echo is based on HTML rendering, supporting XHTML was extremely easy.  For
completeness I also made efforts to support the XUL box model.  This was
certainly an interesting piece of code, but I believe that its actual
value may not be worth the cost of finishing and maintaining it.  It is
pretty interesting to have constraint based interfaces that "snap to" the
right size, but it may not be intersting enough to justify the work and
complexity.

You hit the nail on the head when you highlighted the differences between
how the HTMLTemplate layout manager and EchoXUL do things.  The
HTMLTemplate system takes the approach of laying out existing Component
instances by "decorating" them with HTML before and after each instance
(along with some ability to set visual properties on the component
instances).  EchoXUL is more analagous to the resource factory paradigm
used by native GUI implementations (ie. Windows, MacOS, etc).  With this
paradigm there is a resource controller which instantiates an entire
structure of components and presents them to the instantiating controller
in the form of id handles of some type.  In this regard, the EchoXUL
framework would not fit well into the idiom of LayoutManagers which
HTMLTemplate is based on.  A LayoutManager is a consumer of pre-created
instances, whereas the EchoXUL view framework is a factory for creating
Component hierarchies.

In hindsight, I regret naming the project EchoXUL, because I think the
cogent idea that makes this project unique is not its use of XUL as the
primary means of describing views.  I think the real meat of the matter
comes from the "View framework" (ie. the interfaces and classes under
echoxul.view).  It is this part of the API that is nuetral as to the
underlying representation (ie. XUL, HTML, etc).  I could really take or
leave using XUL to describe Echo UIs, but I would really like to see a
robust Component factory and location framework similar to that
implemented by the echoxul.view package.

By having such a factory pattern for creating Component hierarchies and
providing the ability to "cross-cut" directly to the active components or
sub-factories that form the interactive part of the interface, it allows
the Echo developer great freedom to create better controller Components
that are less concerned about the mundane details of layout and visual
control and are more concerned about orchestrating the events and flow of
the application.

That such a pattern can be extended (as I have done with EchoXUL) to load
its resources from external files which are in a format that is familiar
and common to many people and tools is really just an added bonus.

Anyway, I could discuss this type of thing for a long time and if we were
within close proximity, I would take you up on that beer.  I think that
the Echo framework is just about the coolest thing I have ever seen.  I
find myself unable to stop evangelizing it to my coworkers (and even my
wife, who could really care less!).  I give my endless thanks to the folks
at Nextapp and Brad for their tireless effort on this stuff.

If my contribution starts a discussion which enhances Echo then I will
consider the time well spent.  If my implementation is used, then all the
better, but that is not my goal.  I really just wanted to illustrate these
concepts with something more than words and a spec.  I wanted to show
people what I had in mind.  If you come back and say I'm crazy I can take
that and find another way to contribute.

As for some of your other specific comments:
   - Sorry for the wrong extension on the source distro.  It was my first
time using the Sourceforge file repository and it seems to have edited
my file name.
   - The NestedHTMLComponent was optimized and created to exist as part of
the View framework and would therefore not be extremely useable outside
of it.  However, it is a fairly trivial component and a generic
implementation could be easily created.  The main thing that this
specific component does is utilize the view framework to store static
content at the server level instead of for each session.  This keeps
each new instance from incurring the memory cost required to store the
static HTML pieces.  Some of the other components such as XulBox and
SafeWrapperComponent (for catching exception from UI peers) are general
and not tied to the EchoXUL framework.
   - I wish I could find the guy who wanted to do the incremental refresh
stuff.  That would be really cool.  I have had similar thoughts, but I
don't think I ever said them out loud -- so I don't think I'm the
person you're referring to! :)
   - I'm not mad at you.  I burst on the scene with what appeared to be a
competing implementation.  This is my first real foray into open source
and I probably deserved to get hit on the head, but I instead received
a very detailed and sensible response.  Thanks.

BTW - I am wondering if anyone is planning or writing a killer Echo app. 
The problem with this framework is that most of the best uses for it are
"behind the firewall".  Brad and the Nextapp folks have done a wonderful
job with their demos, but I think we really need an Open Source app with
some sizzle... perhaps a content management system, weblog manager or
wiki.  Any thoughts?  I want something that I can take to skeptics and say
"look what you can do with Echo".

Terry

> Congrats Terry
>
> Nice to see that Echo comunity grows,  even to XUL direction,  I just will
> make the request that we dont start a fight over the isue "XUL is bad /
> XUL
> is great" on this list.
> It only changes the "init" function of GUI and the author says it cleanly,
> I
> dont like when someone proclaims XUL as "solution for everithing".
>
> I like the possibility to include ordinary HTML in XUL file but I dont
> know
> how is this going to work with existing templating stuff
> (HTMLTemplatePanel). So now we have something wey similiar : we can write
> HTML templates with a way to insert echo components in it by marking the
> place in HTML or just puting the name attribute in the supported tags. AND
> now we will have XUL text files with XUL syntax for composing Echo
> components and around them there may be plain XHTML (via
> echoxul.component.NestedHtmlComponent  (I wonder is this a full component
> that can be used without full XUL, I mean just to include it in normlal
> Echo
> screen programaticaly ?)).
> Maybe this new XUL stuff should be only a syntax for including Echo
> components in HTML Template for HTMLTemplatePanel  of  Brad Baker.
>
> Anyway there is an overlap and IMHO mybe it could be addressed to make it
> that way so there is no overlap and that there is still support for XUL
> from
> Terry Laurenzo (if both Brad and Terry have time and are willing to
> cooperate).
>
> Only MAJOR difference that I see between EchoXUL and HTMLTemplatePanel is
> that when we parse and use the HTML template, components are allready
> instantied and just mounted to place (HTMLTempltePanel is more to layout
> that composition)  and EchoXUL is also about layout but also for
> instatiating components (XUL tags).
>
> So IMHO now I see two ways :
>     1. dump the XHTML support in EchoXUL and make the EchoXUL works nice
> with existing way of adding ordinary HTML (HTMLTemplatePanel)
>     2. or total integration of  HTMLTemplatePanel nad EchoXUL (they anways
> probably both have ).
>
> Of the other things I notice that you are doing layout at client side ?
> ("In EchoXUL, a monsterous JavaScript based XUL layout engine is used to
> dynamically enforce XUL constraints.")
> We will se how it is going to work with HTML generated from Echo/EchoPoint
> components, but even if there is going to be problems I think that they
> are
> going to be easily solvable.
>
> And for the end  , Brad, Terry, PLEASE don't get mad at me for commentig
> at
> your work, but I like Echo/EchoPoint and I would like it to be concise and
> clean because it is why I love it.    You would get a beer from me
> anytime.
>
> BTW: Terry please rename "echoxul-0.1-source.gz" to
> "echoxul-0.1-source.tar.gz" and make the file inside the gz also have .tar
> extension. Or just put the .tar extension to file inside gzip archive
> (khm... I am on windows so I cant unpack before the file has right
> extension).
>
>
> Cheers, Domagoj
>
>
> BTW2 : But where is the guy that said that he will try to work on making
> Echo support "partial updates" (with fallback to whole HTML_Frame /
> Echo_Pane    refresh if browser cant support it) , I just wonder is he
> working on something ?
>
>
>