El sáb, 27-08-2005 a las 21:27 -0600, Randy Watler escribió: > Santiago Gala wrote: > > >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.
> 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: [EMAIL PROTECTED]
> >>>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>>
> >>>>
> >>>>
> >>>>
> >>>__________________________________
> >>>Save the earth
> >>>http://pr.mail.yahoo.co.jp/ondanka/
> >>>
> >>>
> >>>---------------------------------------------------------------------
> >>>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>>For additional commands, e-mail: [EMAIL PROTECTED]
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>---------------------------------------------------------------------
> >>To unsubscribe, e-mail: [EMAIL PROTECTED]
> >>For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
signature.asc
Description: This is a digitally signed message part
