Santiago Gala wrote:
>
> Raphaël Luta escribió:
>
> I like the way pull ideas are applied here. We are getting closer to get
> an Application model (the toolbox?). The separation between model and
> view is much clearer now. Also the way we manage administration vs user
> configuration.
>
> I have mostly one problem, related with the 0, 1 or infifity rule (You
> advocate 1 pane, I ask for infinity :):
>
I don't advocate 1 pane.
* 1 pane will likely be the best approach if an administrator wants to create
a "personal information dashboard"
* n panes mixed with non-jetspeed object will probably be the best solutions
for public portals or non-portal customizable sites
> (...)
> > Note 2:
> > The new PSML syntax will have the following properties :
> > - no recursive definitions: a pane element cannot contain another pane
>
> I think this is not good. In fact, a screenlet is only the specification
> of what to show in a rectangle in the page. The page is a rectangle
> itself. It is natural to specify layout in terms of included rectangles
> (a recursive definition).
>
> Do you have good reasons to make this proposal? I think we can design it
> with recursion.
>
I concur, but just because the model let infinitely recurse is not a good
reason for allowing infinity recursion, that the (in)famous Stefano's FS
anti-pattern.
Just look at Turbine layout modules for a layout model which specifically
chosed not to be recursive.
Since Jetspeed will extend Turbine model, I think it's better to try and
stick with the base design...
Also I think it would be very hard to make recursive process work
effectively performance-wise whereas it's much easier to optimize "flat"
algorithm implementations.
> In addition, I'm using a left hand side pane containing top panes in the
> layout of a couple of sites :)
>
Can you give me your PSML structure, I'm pretty sure this can be expressed
without recursion ?
> I know we could do that using navigations, but we are breaking the
> natural behaviour (any rectangular region is a screenlet, no matter the
> complexity it hides).
>
> Later in the thread, you state:
>
> >(David)
> >> Is a Layout Manager something like a 'controller'?
>
> >Yes.
> >Layout managers will certainly be more complex than controllers
> >because you can't nest panes so we'll need something like "MultiColumnLM"
> >whereas in PSML the simple RowColumnController was enough for any tabular>
> >display requirements.
>
> This outlines my fears: we are trading elegant complexity at the core
> layout algorithm by (possibly messy) complexity in the implementation of
> the Layout managers. I don't think it is a good deal in the long term.
>
I would expect 90% of the real portal needs will be addressed by a
MultiColumnLM (and possibly a GridLM).
A GridBagLM (or an AbsolutePositionLM) could fill the rest of the very
complex needs without recursion.
The current functionality offered by the PanedControl/CardController can
be handled differently by specifying separate panes.
> (...)
> > Multi-device operation
> > ======================
> > * It is anticipated that a given portal configuration will usually only
> > support one media-type (for example: default HTML conf, default WML conf,
> > etc...).
>
> I don't agree with this statement. I foresee four core media types:
>
> text/html (with browser variants)
> text/wml (at least for a couple of years)
> application/pdf (I would like to offer a printed version of a portal as
> a PDF doc, where panes are sections. A wishlist item :)
> swing/j2me (A portal sends you an applet or a midlet that builds the
> user i/f on your device, according to your spec). Another dream :)
>
> We should strive for having a design (in the long term) that allows us
> to reuse the same specification of content and layout for the four media
> types, which includes:
>
> - severe limitations in size or capabilities. Your adapter idea for WML
> looks very promising here. It could be reused for things like having
> different browser capabilities resulting in "adaptations" of the core
> content for javascript, ...
> - "mise en page" (pagination? I don't know in english) of content. There
> XSL-FO has a lot to offer, but there are fundamental issues. This is
> very specific of the PDF stuff. I'm trying to map the portal structure
> with a document structure.
> - distributed dialog/state (some event can be executed in applet, some
> in server). This applies also to the Adaptor handling of forms and
> internal navigation in the chunks.
>
I fail to see where you don't agree.
The pane specification will never be device dependant but if the media-type
capabilities are very different, most people will want to have different
content adapted to the capability of the accessing device.
Adaptation can be handled by post-processing gateways (for example the
WebpagePortlet or the Adapter mechanism) which may be embedded in jetspeed
as portlets.
Full-device independance is also a factor of the underlining templating
system (and most systems don't make provisions for these kind of issues
leaving this responsibility entirely on the site developper).
> > Items yet to be defined
> > =======================
> > * All the markup languages used for configuration need to be completely
> > specified
>
> Yes. We could offer a syntax where recursive panes can be an optional
> feature, free to be implemented or not by the portlet container
> provider. What do you think?
>
This has nothing to do with the portlet container, the markup defined
is Jetspeed specific since it's related to the layout configuration
model of Jetspeed.
> > * The jetspeed toolbox available whithin templates must be fully
> > described
>
> This is important. We are thinking on how to implement the toolbox as a
> SAX content handler, that will be used by XSLT templates. That is what
> we are doing currently with Turbine Contexts --> a context is a DOM
> document or a SAX content handler, and the template uses it to generate
> output. We have two working implementation of this, a DOMTemplateService
> and a SAXTemplateService.
>
> Is there a toolbox per portlet (in the sense Application Model) or just
> one for the system as a whole?
>
A toolbox is a generic access object for your business elements, so there's
not one per portlet, which a concept which probably won't appear in the
toolbox anyway :)
> > * Should we allow the use of variables as entry parameters within pane
> > definitions ?
>
> You mean expressing customizable items like this? I don't get it
> completely.
>
I was thinking about allowing config elements constructs that refer to
expected request parameters values.
It would be very powerful but also quite tricky to implement well (think
of how the customizer would handle this) and may muddle too much the
separation between user options and site implementation.
I left it out of the proposal because of this but I'd like to have the list
opinion on this.
> > * Are there any specific requirements for handling form submissions ?
>
> A portlet administrator should be able to register handlers for events
> (like minimizing, ...) both standard events and portlet specific events
> (logout, check_mail, ...)
>
> The portlet container should allow the template writer to express these
> events and ensure that the specified handler is called.
>
I don't understand exactly what you mean here, can you give precise examples
of what you have in mind ?
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
