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.
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: [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]
__________________________________
Save the earth
http://pr.mail.yahoo.co.jp/ondanka/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
