+1.
This should be very beneficial for anyone who wants to pump content
different ways.
Santiago Gala wrote:
>
> 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]
--
--------------------------------------------------------------
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]
