Rapha�l Luta wrote:
<snip>
> > Yes. The problem is that the above controllers all assume HTML. the
> > WAPPortletController should work with WAP decks.
> >
>
> No, there're not dependant for their functionality on any output format, a column is
> always a column whether it's rendered in HTML, PDF, SVG or Flash, same for grids,
> etc...
> The issue with WML 1.1 is that it allows very limited presentation options but WML
> 1.2
Yes. But the problem is that currently we have VERY small WML devices.
I can't have Portlets arranged in a table with this mechanism :(..
Technically I could but about 80% of devices couldn't render them.
Truth is it should be a WMLDeckPortletController. :)
> is already changing this (introduced <table> last time I checked...).
> Writing a WAPPortletController implies that there can't be 2 WAP controller
> coexisting,
> just like writing an HTMLPortletController would mean there should be only one
> controller for HTML. This doesn't make sense to me.
IMO WML is already a dead technology. The only reason it exists is for
downlevel clients. As soon as cellphones get one large LCD panel and
they are running Linux/Mozilla (drooolll :) we won't need WML anymore.
This is why providing advanced layouts to these type of devices isn't
really practical. IMO. By the time the screens get large enough to
hold 2 Portlets at once we can just run Mozilla :)
<snip>
> > > Advantages:
> > > * This provides the best control over the features available in a given
> > > format, we can use different controllers, layouts, etc... specifically adapted.
> > > * This is very easily implemented, just write a Profiler
> > >
> > > Disadvantages:
> > > * there's an aadditional user action required for subscribing/unsubscribing a
> > > portlet for different output format.
> >
> > Right. This is why I want to uses <set>s in my updated proposal. It is
> > almost impossible to write a subscription engine without this. How do
> > you organize sets without some really bad AI trying to figure this out?
> >
>
> Don't understand this question. Can you provide a use case so that I can grasp the
> issue ?
OK.
Imagine a really complex layout. With PSML it is very easy to build a
massivly complex GUI. This is both good and bad. If you want to add a
Portlet to the current layout... where do you add it. IE:
- users launches the Customizer
- user chooses to navigate multiple controllers within that PSML file.
- User wants to add PortletX to a section on his screen.
- 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.
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 :(
<snip>
> Cocoon allows for easy implementation of WML, HTML, etc... rendering but doesn't
> address, per se, the WML constraint space (like redefining titles, limiting output
> size, etc...)
Yes. This is a problem. We need to 'massage' the data. We can
probably do this with decent stylesheets.
<snip>
> > The problem with this is that you need to take a .psml file and provide
> > a COMPLETE UI for this. Right now I want to take this .psml file and
> > make some assumptions (that it uses a 2 column layout) and then build
> > from there. We can add more complicated layouts later.
> >
>
> As long as we can build more complicated issue, I don't see why we can't pre-set
> some options to simplify the initial implementation, but I'd hate to see some layout
> assumptions in the customizer API...
Yes. It can be done correctly without layout assumptions but only if we
use the <set> proposal. Otherwise we can't really figure out how to
build this.
... just thinking out loud. We could implement this by using the DOM's
id() of the current <portlet> node. The only problem is that Castor
won't give this to us. I might be able to trick it into doing it with
an xmlschema hack.
<snip>
> > Yes you can... :)... I didn't provide an example but you can nest
> > controllers. :)
> >
>
> This is definitely not evident from your markup example ! Can you provide us
> a *complete* example or schema (with layout, skin, metadata properties and
> complex layout output), just for the sake of discussion ? ;P
yes. let me get back. My initial e-mail was just to get feedback. I
wanted to get some feedback on my proposal before it became a a chore to
build out :)
--
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]
