burtonator wrote:
>
> Rapha�l Luta wrote:
> <snip>
> >
> > Maybe in the US, but I have a very nice Nokia GSM Phine with a large screen ;P
>
> The are getting nice... http://www.nokia.com/phones/9110i/
>
Yes, that's the one. :)
> <snip>
> > Actually, in the PSML users don't deal with controllers, they deal exclusively with
> > PortletSets. The controller is just a property of a specific set.
>
> Yes... but the point is that this isn't really want the user cares
> about.. They want to see how that set is rendered.
>
Agreed, my point was just that the customizer does not need to be aware
of controllers except as a property to set in a given portletset.
If you want to preview a portletset, just instanciate and call getContent().
> > > - User wants to add PortletX to a section on his screen.
> >
> > so far, so good
> >
> > > - At this point the Customizer where in the PSML document to place the
> > > Portlet. It can't go by using the currently selected Portlets name/ID
> > > because this may have been added twice within the document.
> > >
> > I don't understand these sentences, some words are missing or my English is
> > failing me.
>
> Maybe if I used proper English... must have been late. Let me rephrase:
>
> - At this point the 'Customizer' needs to know where in the PSML
> document to place the Portlet. It can't determine this by using the
> currently selected Portlets name/ID because this may have been added
> twice within the document.
>
Still not really sure what your point is. I believe you are saying that once a user
has chosen a Portlet there's no easy way for the customizer to let him chose
where he wants to put it. I thought my step by step process or XSLT transformed GUI
described in my first reply would be enough.
> > > This is why we need to use named sets (even if we just use numbers).
> > > When the user selects a Portlet I can have it also select a set. This
> > > way when the user selects 'Add Portlet' the Customizer knows correctly
> > > what set he needs to add this to. The problem is that since PSML can
> > > have theoretically nested <portlets> we can't figure this out without a
> > > kludge :(
> > >
> >
> > I'm not sure I understand you, but if we have a Portlet GUID system, since
> > PortletSet are subclasses of Portlet, you can get a direct reference to a
>PortletSet
> > whatever the nesting level...
>
> ug.. yes. That would be correct. But if we use Cocoon to XSLT this
> from PSML to a UI (which is what I wanted to do), Cocoon will never see
> the PortletSet because it is in Java and not XML. It needs to be global
> across XML and Java..
Well, XML <portlets> <=> Java PortletSet just as XML <entry> <=> Java <portlet>,
I don't see why we can't write the GUID in the PSML.
>
> <snip>
> > I'm waiting on your markup example to comment on this. I can think I can picture
> > a way to write a Customizer covering most cases with the current PSML but if your
> > solution is simpler it may be worth it, as long as we don't lose any functionality.
>
> I looked at it... Everything seems to match up correctly. Do we need
> <layout position="1"> (I mean just the position attribute). Can't we
> just use the way it appears in the DOM?
>
> This seems to bind layout to the set. I would rather just assume the
> default.
>
This is due to a limitation of the PortletSet factory, implied by the use of Castor.
- Castor doesn't let you access all the children of a given element, so you must
query them by type.
- Castor doesn't handle type inheritance so can't put a relation between <entry>
and <portlets> elements.
All this means that when the factory needs to instanciate a set, it first queries and
instanciate all <portlets> children of this set and then all <entry> children. So if
you have in your PSML a set with mixed content (<portlets> and <entry>), your <entry>
will appear after the <portlets> whatever their order in the PSML unless you
explicitely include the layout position.
If you have only homogeneous portletsets, you can go without <layout position=""> and
rely on document order. For the purpose of building a simple customizer, you can
chose to never mix content and never put position attributes.
Once the Castor issue is dealt with, either by improving Castor or using a straight
XML parser to handle the files, layout would only be required for constraint-based
layout strategy such as the mythic GridBagPortletController. All the currently
implemented controllers can work properly xith the implicit position (except grid
but it very simple to patch).
--
Rapha�l Luta - [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]
