Re: mediatype handling [Was: svn commit: r239538 - /portals/jetspeed-2/trunk/etc/sql/populate-db-default.sql]

[Santiago Gala <sg...@apache.org>]

El lun, 29-08-2005 a las 07:56 +0900, Shinsuke SUGAYA escribió:
> Santiago Gala wrote:
> > El sáb, 27-08-2005 a las 21:27 -0600, Randy Watler escribió:
> >>>El jue, 25-08-2005 a las 07:59 -0600, Randy Watler escribió:
> >>>>Shinsuke,
> >>>>
> >>>>To be clear, I am not in favor of changing the default configuration of 
> >>>>J2. However, I think a standard profiling rule should be added so that 
> >>>>one can simply use the UserManagement administration to change the 
> >>>>default profiling rule and user profiling rules after deployment. If we 
> >>>>add a new rule, mediatype should be removed from the base 'j2' rule.
> >>>>
> >>>>The reasoning here is that I think the common web portal does not 
> >>>>require mediatype to be profiled and the extra directory structure may 
> >>>>just be plain annoying. Of course, this is just my opinion. If you want 
> >>>>to modify the default profiling rule configuration as we have 
> >>>>discusssed, I think a vote should be required.
> >>>
> >>>Not sure about that.
> >>>
> >>>The ajax implementation will most likely require to have requests that
> >>>want "text/xml" or "application/xml" be served with a completely
> >>>different layout for the aggregation of the page, a
> >>><ajax-response><response>...</response></ajax-response> one.
> >>
> >>Understood.... but the profiler is about selecting PSML. I would think 
> >>that generating different aggregation/layout/rendering results should be 
> >>handled elsewhere. I can understand using different PSML for small 
> >>mobile devices... those would seem to need different PSML pages/site 
> >>definitions. I am not sure why AJAX integration would  require different 
> >>page models.
> > 
> > My wrong. I mixed concerns in my comment. I was actually thinking that:
> > - either we support properly different mime-types than text/html in the
> > existing layout
> > - or we need to have a different layout in pages for ajax support.
> > 
> > The same happens to Shinsuke if he wants to have xhtml-basic support:
> > the current line in Layout.java will send back text/html unless changed
> > to do content negotiation or else don't mess with the content type set
> > by an upper layer in the portal.
> > 
> > Not sure if now we implement any sort of content negotiation between the
> > portal and portlet supported mime types and the request.
> 
> I think that mediatype handling is related to capabilities issue.
> In my case, XHTML Basic has to return application/xhtml+xml as
> mediatype. My understanding is, I expect CapabilityValveImpl sets
> it based on the user agent(but it seems not to work right now..).
> So, I think  J2 binds 1 user agent to 1 mediatype. But, in AJAX
> integration, it seems to be bound to multiple mediatype. So,
> I'm not sure if the current capabilities supports your concerns.
> 

I checked the code, and request.getResponseContentTypes() currently
returns always "text/html" as the only option (hardcoded in
DynamicInformationProviderImpl in pluto). This is the bad news.

The good news is that neither pluto nor jetspeed is actually checking
that the portlet (layout in my case) is using a value there, so I can
change the value in the layout code and it will pass through the whole
portal aggregation without problems. (It looks like this adds to two
violations of the spec in a row, though I have not read the details)

So, for the moment, I'm skipping this issue and just taking care of
Content type in the Layout component for ajax or "plain" pages, as the
Google grant is ending and we need results.

But I'm guessing that we'll need to either send a patch to pluto
(container.core) for this code or implement our own
DynamicInformationProvider in jetspeed, taking care of mime type
negotiation between the user agent and the portal, on one side, and the
portal and different portlets, on the other.

Just to give an example: Imagine we are using ajax layout and some of
the portlets in the page are not supporting it, while other portlets
have registered ajax hooks.

We would need to ask for "text/html" in render (in View mode) for
non-ajax portlets, but integrate this information in an ajax response
together with "proper" (Ajax mode, text/xml, different response element)
ajax responses sent by other portlets.

This is greatly speculative, we are at the "proof of concept" stage now.
In fact, Juan and myself are trying to put up a demo with ajax layout
and "normal" portlet response, and also to get one portlet (probably the
databasebrowser) use ajax inside this loop.

Based on the results, we'll present a proposal for integration of ajax
services in the portal, as well as ajax layout as a whole. Not really
different for jetspeed as we do layout with plain portlets.

Regards
Santiago

> Thanks,
>   shinsuke
> 
> 
> >>Randy
> >>
> >>
> >>>I'm having trouble with the following line in Layout.java:
> >>>
> >>>response.setContentType("text/html"), for instance.
> >>>
> >>>It disables any use of Layout.java for non "text/html" pages. 
> >>>
> >>>My view of ajax integration is that we would have a layout that would
> >>>send all[1] data to the browser as an <ajax-response>. The browser would
> >>>then use javascript to update portlets/menu/navigation/action info.
> >>>
> >>>[1] all for the first prototype. After we get caching in place, only
> >>>those portlets having changed would be sent back to the browser.
> >>>
> >>>Regards,
> >>>Santiago
> >>>
> >>> 
> >>>
> >>>
> >>>>Randy
> >>>>
> >>>>Shinsuke SUGAYA wrote:
> >>>>
> >>>>   
> >>>>
> >>>>
> >>>>>Hi Randy,
> >>>>>
> >>>>>Thanks. I'll try ../pages/_mediatype structure to check if
> >>>>>the problem I encountered is resolved, and then I'll update
> >>>>>the JIRA issue.
> >>>>>
> >>>>>Regards,
> >>>>>shinsuke
> >>>>>
> >>>>>Randy Watler wrote:
> >>>>>
> >>>>>     
> >>>>>
> >>>>>
> >>>>>>Shinsuke,
> >>>>>>
> >>>>>>Shinsuke SUGAYA wrote:
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>
> >>>>>>>Randy Watler wrote:
> >>>>>>>
> >>>>>>>         
> >>>>>>>
> >>>>>>>
> >>>>>>>>Shinsuke,
> >>>>>>>>
> >>>>>>>>In that case, you need to use a different profiling rule for those 
> >>>>>>>>customers or make sure that all the page content exists in the more 
> >>>>>>>>specific content directory.
> >>>>>>>>
> >>>>>>>>The latter is probably too tough to live by for long. However, a 
> >>>>>>>>new profiling rule is trivial that will support multiple devices 
> >>>>>>>>per user. For example, you could use mediatype:xhtml:user:user that 
> >>>>>>>>results in the following directory structure:
> >>>>>>>>
> >>>>>>>>.../pages/_mediatype/html/user/user/....
> >>>>>>>>
> >>>>>>>>and
> >>>>>>>>
> >>>>>>>>../pages/_mediatype/xhtml/user/user...
> >>>>>>>>
> >>>>>>>>Of course, this implies that shared content has to be moved from 
> >>>>>>>>"/" to "/_mediatype/XXX" folders. I do not feel that that the 
> >>>>>>>>default J2 profiling rule should use this technique, but rather 
> >>>>>>>>that we should have a new rule like j2-mobile or something like 
> >>>>>>>>that... thoughts? About the only drawback to this approach is that 
> >>>>>>>>the "new user" support would have to know to create the user pages 
> >>>>>>>>in both folders... (something we needed to do anyway: need to 
> >>>>>>>>extend/create a JIRA issue for that).
> >>>>>>>>           
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>>If creating a new profiling rule, we have to apply it to guest user in
> >>>>>>>order to display the proper default page for each device. So, I feel 
> >>>>>>>that
> >>>>>>>the above directoy structure may be proper.. Anyway I'll create as 
> >>>>>>>JIRA issue.
> >>>>>>>         
> >>>>>>>
> >>>>>>
> >>>>>>Yes. Since we are talking about a new profiling rule for the entire 
> >>>>>>site, I would expect that all users, including guest, would use the 
> >>>>>>new profiling rule. Let me know if you need any help authoring the 
> >>>>>>rules/criteria. This seems like the easiest, (and hopefully best), 
> >>>>>>way to solve the problem you are encountering with the out-of-box 
> >>>>>>configuration.
> >>>>>>
> >>>>>>Randy
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>>
> >>>>>>>Thanks,
> >>>>>>>shinsuke
> >>>>>>>
> >>>>>>>         
> >>>>>>>
> >>>>>>
> >>>>>>---------------------------------------------------------------------
> >>>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>>>>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>>>>
> >>>>>>
> >>>>>>       
> >>>>>>
> >>>>>
> >>>>>__________________________________
> >>>>>Save the earth
> >>>>>http://pr.mail.yahoo.co.jp/ondanka/
> >>>>>
> >>>>>
> >>>>>---------------------------------------------------------------------
> >>>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>>>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>>>
> >>>>>
> >>>>>
> >>>>>     
> >>>>>
> >>>>
> >>>>---------------------------------------------------------------------
> >>>>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>>>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>>>
> >>>>   
> >>>>
> >>
> >>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> >>For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> >>
> 
> __________________________________
> Save the earth
> http://pr.mail.yahoo.co.jp/ondanka/
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: jetspeed-dev-unsubscribe@portals.apache.org
> For additional commands, e-mail: jetspeed-dev-help@portals.apache.org
> 
-- 
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation