(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>
> >
> > ********************************************************************************
> > 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.
yup.
> > 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)
> >
<snip>
> 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).
how is this :)
<profiles>
<!--
media-type specifies the media (and hence CapabilityMap to base off
of)
name is associated with the profile-entry
-->
<default-profile-entry
media-type="html-lite"
name="default-html-lite"/>
<default-profile-entry
media-type="html"
name="default-html"/>
<default-profile-entry
media-type="wml"
name="default-wml"/>
<profile-entry url="/content/profiles/default-html-lite.psml"
name="default-html-lite">
<metainfo>
<title>Default HTML Lite Profile</title>
<description>
Profile for browsers that don't support high level HTML
</description>
</metainfo>
</profile-entry>
<profile-entry url="/content/profiles/default-html-lite.psml"
name="default-html-lite">
<metainfo>
<title>Default HTML Profile</title>
<description>
Profile for uplevel browsers (Mozilla, IE).
</description>
</metainfo>
</profile-entry>
<profile-entry url="/content/profiles/sports.psml" name="sports">
<metainfo>
<title>Sports</title>
<description>
ESPN and various sports channels.
</description>
</metainfo>
</profile-entry>
</profiles>
> > 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 ?
********************************************************************************
6. Rework the Registry mechanism.
********************************************************************************
Build out a new package: org.apache.jetspeed.registry.
There should be a base interface: Registry with multiple
implementations:
- PortletRegistry
- PortletControlRegistry
- PortletControllerRegistry
- ProfileRegistry
- CapabilityMapRegistry
- MediaTypeRegistry ( see item 7 - MediaType registration )
> > Profile:
> >
> > + public String getHREF();
>
> rather getURL() since that would be consistent with the other APIs.
yup... now in CVS.
> > + 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
DONE.
> >
> > ********************************************************************************
> > 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,
yup.
> 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>
I added this code snippet to the PROPOSAL
> > ********************************************************************************
> > 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:
See below for a media-type proposal
> > ********************************************************************************
> > 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
<snip>
********************************************************************************
7. MediaType registration
********************************************************************************
(NOTE:. There is a slight overlap with Cocoon functionality. Merge
this into
Cocoon 2.0 -> Jetspeed 2.0 when the time is right)
It is important to allow other publication mechanisms besides MimeType
publication.
- The text/html MimeType can mean many things. Table support,
JavaScript, etc.
It is important to have multiple HTML media types registered. Some
thin
clients can render HTML but only if they don't use Javascript or HTML
4.0
features (tables, CSS, etc).
- The text/xml MimeType is even more confusing. There can be multiple
namespaces under this mime type that we should publish to.
There should also be a mechanism for Jetspeed to bypass the automatic
MediaType
guessing provided by UserAgent. An HTML web browser ( Mozilla ) might
actually
want to request XML for an XSLT transformation. In this case Jetspeed
should
accept a /media-type/ocs (for Open Content Syndication namespace) URL.
The registration process allow the following markup
<!--
Registers all media types available within Jetspeed.
-->
<media-types>
<media-type-entry name="html-lite">
<capability-map>
...
</capability-map>
<metainfo>
...
</metainfo>
</media-type-entry>
</media-types>
--
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]
