Raphaël Luta escribió:
I agree with most of your proposal. I think it is excelent, and we are
going the right direction to get something usable and workable.
Sorry for the delay in answering, but I wanted to understand it
completely before jumping in.
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 :):
(...)
> 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.
In addition, I'm using a left hand side pane containing top panes in the
layout of a couple of sites :)
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.
(...)
> 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.
> 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?
> * 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?
> * 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.
> * 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.
That is what your post suggests me right now :) I'm happy you are
organizing our disperse thinking (at leat mine).
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
