David Sean Taylor wrote:
>
> >
> > IMO, the default language configuration is unnecessary, the
> > fallback mechanism
> > to "default.psml" implicitely handle this case.
> >
>
> True, the fallback mechanism can handle it.
> I was thinking of situations where you need to change the default language
> per installation.
> In this case you don't have to go about renaming files. Instead you simply
> change the configuration file.
>
You're right but I don't see this happening a lot and the "implicit" fallback
is more natural for me since it's already what is implemented in java for
ResourceBundles and in Apache and NES for handling language negociation...
> >
> > I don't like using a CapabilityMap as an explicit parameter in
> > the Profiler
> > interface, this creates an unnesssary coupling of interfaces.
> > Either the capabilityMap is a service and is used implicitely within a
> > getProfile implementation or (my preferred solution) a
> > getCapability() method
> > is added in RunData and populated by the CapabilityMap before the
> > call to the
> > profiler.
> >
>
> RunData is part of Turbine. Have you made any suggestion there yet?
> Currently, the CapabilityMap is not a service.
Jetspeed will use its subclass of RunData in a near future in any case
because it's required for properly storing PSML configs and PSML elements
template info.
Also the capabililyMap is currently misnamed, we really should have 2 distinct
components:
- a CapabilityMap, which can be easily implemented as a Turbine service which
uses the user-agent description to create a Capability object for the request.
The Map builds the information from its own browser description table which can
be stored in any format you like.
- a Capability object which is an object rdescribing the current capabilities
of the user-agent for the current session. As such it should be naturally found
in HttpSession, but since it's not, RunData is the next most logicial place
to store the Capability object.
This can definitely be part of core Turbine. The nice thing about this is that
the only change needed to support CC/PP is extending the CapabilityMap service
to build Capability objects for parsed CC/PP headers.
> >
> > > /*
> > > store cookie in response to the current resource
> > > */
> > > storeCookie();
> >
> > I'm not sure how you plan to use this. Can you provide a pseudo-code
> > example ?
> >
>
> The user of the service would call this method to write a cookie into the
> response.
> Looks like Im missing a response parameter.
> The profiler could then look for the cookie in future requests in
> getProfile()
>
If you mean you want to write a cookie to in the ServletResponse why not
just use directly the Servlet API calls ?
If the Profiler service implementation needs to set/get cookies for its
correct operation, it can do it transparently through
RunData.getResponse().addCookie() in the getProfile() method.
--
Rapha�l Luta - [EMAIL PROTECTED]
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://marc.theaimsgroup.com/?l=jetspeed>
Problems?: [EMAIL PROTECTED]
