burtonator wrote:
> burtonator wrote:
> >
> > (ug. I just had a HUGE reply for this. Netscape dumped core on
> > spellcheck :(!!!!)
> >
> > Rapha�l Luta wrote:
> > >
> > > burtonator wrote:
> > > >
> > > >
>********************************************************************************
> > > > 1. PortletControls and PortletControllers aren't registered in a central
> > > > location
> > > >
>********************************************************************************
> > > >
> > > > Change <entry> into <portlet>. Also add <portlet-control> and
> > > > <portlet-controller>. Misc code changes within the core.
> > > >
> > >
> > > +1. Even if this may be the code harder to read due to classname conflicts
> >
> > I was thinking this wasn't perfect. I want to rev this one more time:
> >
> > <portlets>
> >
> > <!--
> > Should allow us to put more portlet metadata here in the future
> > -->
> >
> > <portlet-entry>
> >
> > <!--
> > Should map to the peer PortletEntry class better.
> > -->
> > <classname>...</classname>
> > ...
> > </portlet-entry>
> >
> > </portlets>
> >
> > <portlet-controls>
> > ...
> > </portlet-controls>
> > ...
> > <portlet-controllers>
> > ...
> > </portlet-controllers>
> <snip>
>
> OK. Well I am replying to my own e-mail :) I was thinking of a better
> mechanism for the above:
>
> <portlet-registry>
>
> <portlet-control-registry>
>
> <portlet-controller-registry>
>
> <profile-registry>
>
> <media-type-registry>
>
> etc.etc.etc.
>
> Thoughts?
>
We have discussed some possibilities that we would find more compelling that the way
the
layout process is done right now. The issues are:
- We would like to see a "language independent" layout process, i. e., NO HTML during
the
layout.
- Language and media should be taken into account in a rendering process, AFTER the
page
layout is completely resolved.
The idea would be to have a "concrete" PSML (piecemeal?) built recursively during the
page
layout. This concrete PSML would be a XML describing a page (much like the document one
you have for documentation, but augmented with forms, event, action spec, etc).
After the layout engine lays the page out, it will be rendered by a renderer that takes
into account the capabilities of the media (posibly XSLT transformations).
The renderer would know only about the media capabilities and would try best to show
the
page in the best possible way in a given media (WML, ...)
The user preferences would be used to guide the whole process, but they would be made
orthogonal to the rendering process (except the layout chosen, i.e. the user.psml). In
example, if a user chooses "few" items in a channel, the concrete PSML would carry all
the
portlet items. The renderer would choose, for instance, 10 items in a HTML rendering,
3 in
a WAP rendering, and 20 in a PDF rendering, depending on the media capabilities.
In another example, a paned control woul be rendered as a card in WML with the options,
that would jump to the content cards upon selection, but as it is now in HTML.
I know that you all have discussed the whole set of issues here for a while. I would
like
to know if you think such an approach is not sound.
I have developed the analogy that the screen layout and rendering in Jetspeed are
similar
to the process in a window environment. I am trying to separate the layout (device
independent) from the rendering (device dependent). The renderer would be in this case
something similar to a "printer driver" for the given media.
One additional advantage is that the number of layouts cached would be kept
reasonable, if
we could make it depend only on the content and inner layout. The number of renderings
would, nevertheless, depend on the whole set of media types plus the user preferences.
>
> --
> Kevin A Burton (e-mail: [EMAIL PROTECTED], UIN: 73488596, ZKey:
> burtonator)
> http://relativity.yi.org
> Message to SUN: "Please Open Source Java!"
> To fight and conquer in all your battles is not supreme excellence;
> supreme
> excellence consists in breaking the enemy's resistance without fighting.
> - Sun Tzu, 300 B.C.
>
> --
> --------------------------------------------------------------
> Please read the FAQ! <http://java.apache.org/faq/>
> To subscribe: [EMAIL PROTECTED]
> To unsubscribe: [EMAIL PROTECTED]
> Archives and Other: <http://java.apache.org/main/mail.html>
> Problems?: [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
