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.
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]
