Rapha�l Luta wrote:
>
> 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. :)
UG. I would sell my soul to the devil for that one (Bill Gates... are
you listening :)
We don't have that in the US yet :( It has been available for a while
though :(
> > <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().
Yes. That is exactly what I was going to have the customizer do.
<snip>
> > - 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.
There are multiple PortletSets within a give PSML document... how can
the customizer figure out which one without some type of ID/name? :(
> > > 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.
I think we need to change <portlets> to <portletset> and <entry> to
<portlet>
Thoughts?
Also. If a human chooses the GUID it can't really be a GUID. We don't
have enough randomness for 128bit uniqueness :(
> >
> > <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.
uh?? I don't think so .. I mean you could just nest getPortlets() and
keep going until it returns null. This way you can call getEntry() on
your Portlets. Then you can have an array of Entrys that are ordered
correctly. Right?
> 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).
Yes. This is a good point. ug.
It would be redundant. But maybe we can solve this by keeping the
layout and just using may different sets. Each for different layout and
different controllers to use.
Kevin
--
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]
