At 13:20 07/02/2001 +0100, you wrote:
>Maybe I am missing something, but a portlet should not be concerned with
>things like a profiler service. Instead the profiler service determines
>which and how a portlet is called. Again, I may be missing something, but
>that's how I see it and that's why there isn't anything like that shining
>through in the API.
I agree with you that the profiler service as it's currently defined within
Jetspeed has
no direct relation with the portlet API.
The role of the Profiler is to manage the following relation:
Portal Request --> User configuration/custromizations
In the new envisioned "pull" methodology, the request processing flow will be
(when no action is specified) :
(RequestMapper) (Template processing)
+-----------> Template ------------------------------+---->
Response
/ ^
Request |
(Jetspeed AppTool)
\ (Layout) |
+--------> Configuration --------+------> Jetspeed Content
(Profiler) |
|
PortletRunner ------+
(The top branch is pure Turbine processing, the bottom branch is Jetspeed
specific)
Now, there could be a place for a profiling interface in the Portlet API in
order to
support content profiling tools (like Broadvision, etc...) but this is more
a function
of CMS than pure portlet API and can be handled within a specific portlet
implementation.
>WRT, User and UserProfile -- that's a "bug" - it should be "User" only. An
>update will be posted soon (there are a few other things that were reported
>to me).
>
>I still take comments and feedback. Is there no more interest in a new API
>or is everyone busy doing other things?
Busy does not even approach the truth... :(
I'm in the process of reviewing the proposed API and I'll send back my
comments in
a few days but I can already give a few comments:
1- I still believe it's a bery bad idea not to impose a binding output
contract between
the portlet and the container -> I'd like the API to only allow
well-formed XML
document output in order to make outpout post-processing as easy as
possible
(I thought last time we discussed this that the consensus was in
implementing this
restriction)
2- Even without additional Services API, the current proposal may already
be too
large for a generic portal component model.
I specifically don't think we should include getClient() (and maybe
other methods)
in the base interface but rather in a sub-interface (a la
ServletRequest vs
HttpServletRequest).
In it's present state, the Portlet API looks like overkill if I want
to implement
a simple HTML only portal system without any consideration for
multiple devices,
etc...
3- I'm +1 for a consistent use of DynamicData and removal of Servlet-like
setAttribute()...
--
Raphaël Luta - [EMAIL PROTECTED]
Vivendi Universal Networks - Services Manager / Paris
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/[email protected]/>
List Help?: [EMAIL PROTECTED]
