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.
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]
>
--
VP and Chair, Apache Portals (http://portals.apache.org)
Apache Software Foundation
signature.asc
Description: This is a digitally signed message part
