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
>
> ********************************************************************************
> 2. We can't handle user profiles.
> ********************************************************************************
>
> Currently we have a 'default' profile. This mechanism needs to be
> enhanced so
> that we can provide alternative
>
This is not exactly true since the Profiler can choose the default profile, but
we definitely need a more configurable default implementation for this.
> We need to setup a similar mechanism to item 4. In order to handle
> profiles we
> can register them within the PortletRegistry (so they can be accessed
> easily)
>
> <profiles>
>
> <default mime-type="text/html" name="default-html"/>
> <default mime-type="text/vnd.wap.wml" name="default-wml"/>
>
> <profile-entry href="/content/profiles/sports.psml" name="sports">
> <description>
> ESPN and various sports channels.
> </description>
> </profile-entry>
>
> </profiles>
>
> When complete. 'default-html.psml' should become the default Profile
> for the
> text/html mime type.
>
Hmm, I'm not sure this will be enough. I think MIME-type is not good enough
for selection of profile. For example, my mobile phone supports HTML but not
table or javascript or anything advanced. It would be much more appropriate
for these kinds of appliances to have a "HTML lite" default closer to the
WML home page than the full blown HTML.
I picture the new architecture rather like this:
- define <profile-entry> as proposed in a Registry
- define the 'defaults' for various access devices in another configuration
file, which would be used by a more advanced defualt Profiler.
This makes more sense to me, since the default selection is really a matter
of policy (hence configuration specific to a Component) rather than part of the
system resources (which is what the Registry should define).
> This should have a Java mapping of:
>
> PortletRegistry:
>
> + public Profiles getProfiles();
>
> - new classes:
>
> Profiles:
> + public Profile[] getProfileEntries();
>
Why not define an abstract Registry class and provide PortletRegistry,
ProfileRegistry, ControllerRegistry, etc... implementation ?
> Profile:
>
> + public String getHREF();
rather getURL() since that would be consistent with the other APIs.
> + public String getDescription();
I'm uneasy with this because if we have to grow the metadata available (such as
title, language, keywords, etc...) we'll have to modify the Profile API which is not
good.
I'd much rather have:
public MetaData getMetainfo()
and delegate all the metadata stuff to the MetaData class which is supposed to handle
it anyway...
> + public String getName();
>
OK
>
> ********************************************************************************
> 3. We don't have explicit PortletSets within PSML. We are just using
> <portlets>
> ********************************************************************************
>
> All references to <portlets> should change to <portlet-set> in both user
> and
> registry PSML. The root document node needs to change from <portlets>
> to
> <psml> in user PSML. This maps correctly to the Java object PortletSet.
>
> The <portlets> element in registry psml will be removed.
>
Currently <portlets> is strictly equivalent to a PortletSet, but I'm +1 for the
renaming since it'ww be more consistent with the other naming conventions.
However, we'll still have to define a root portletSet for any given PSML file,
so I'd propose this:
<psml>
<!-- whatever markup not currrently defined -->
<portlet-set>
<!-- standard PSML content -->
</portlet-set>
</psml>
> ********************************************************************************
> 4. The PSML is media and mime-type specific
> ********************************************************************************
>
> Use the Profiler mechanism to provide a mechanism to choose PSML based
> on
> MimeTypes and filename mapping. (a default profile will be used if they
> don't
> exist)
>
> If user connects to Jetspeed with a client of text/html then we can
> serve
> up:
>
> /content/users/burton/psml/text/html/default.psml
>
> if they connect with WAP we could hand them:
>
> /content/users/burton/psml/text/vnd.wap.wml/default.psml
>
Once again, I don't feel mime-types will be up to the task all alone. I'd rather
see a profiler implemntation working with these kinds of config:
* a definition of a device class and capabilities (such as full_HTML, pda_HTML,
pda_WML, etc...)
* a mapping between browsers signature and device class
* a mapping between device class and default profile
> ********************************************************************************
> 5. There is no way to uniquely identify a PortletSet
> ********************************************************************************
>
> In default.psml we will provide some basic names. In autogenerated PSML
> we
> will use GUIDs. Since the names won't conflict with the GUIDs (as long
> as this
> remains clear and documented) we should be fine and won't have any
> conflicts.
>
> This will also allow the Customizer to correctly identify which
> PortletSet a
> user wants to add/remove/etc a Portlet from.
>
+1
--
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]
