On 9/22/06, Gary VanMatre <[EMAIL PROTECTED]> wrote:
>From: "Ryan Wynn" <[EMAIL PROTECTED]>
>
> On 9/21/06, Gary VanMatre wrote:
> > >
> > > Such that the clayJsfid of the root clay component would be
> > > interpreted as classpath*:org/blue/usecases/templates/home.chtm or
> > > classpath*:org/green/usecases/templates/home.chtm
> >
> > Ah, I see. The URL would look something like
> http://localhost:8080/myapp/classpath*:/org/apache/shale/error.html
> >
> > That's a funky URL but it seems to be valid. I gave this a test and you are
> only one character from making this work.
> > The view id always starts with a "/". The logic looks for the "classpath*:"
> at the start of the resource.
> > If it starts with "classpath*:", the class loader is used rather than the
> servlet context to load the resource.
>
> Do you think it would okay if we changed the load from class loader
> logic to look for either classpath*: or /classpath*: at the start of
> the resource? Then the view id can be kept consistently with the /.
>
> Would something like this in ClayViewHandler:renderView work?
>
> String viewId = normalizeViewId(view.getViewId(), index);
> view.setViewId(viewId); // always starts with /
> component =
> context.getApplication().createComponent(CLAY_COMPONENT_TYPE);
> ((Clay) component).setId(CLAY_VIEW_ID);
> if (mappedToClasspath(viewId) {
> ((Clay) component).setJsfid("clay");
> ((Clay) component).setClayJsfid(stripLeadingChar(viewId);
> } else {
> ((Clay) component).setJsfid(viewId);
> }
> ((Clay) component).setManagedBeanName(getManagedBeanName(context, viewId));
> view.getChildren().add(view.getChildren().size(), component);
> }
>


That seems reasonable and an interesting idea.  Please create JIRA issue on it.


Thanks for entertaining the idea!  Not sure if this would be really
beneficial to all apps, but I have a situation where I have a bunch of
portlets that all use common processes that involve 3-5 pages.  This
will allow me to encapulate the views, navigation, and business logic
for those 3-5 pages in jar files and pretty seamlessly just drop the
jar files into the portlets.  Also, the portlets do not necessarily
have to commit to "full xml views" or do the html-xml suffix juggling
(which being done with a servlet filter was not easy to do in a
portlet in the first place).



Gary

Reply via email to