Rapha�l Luta wrote:
>
>
> 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...
>
The 'implicit fallback' is still there.
In fact it is the default mechanism in the proposal, the configuration
method is turned off by default.
The configuration is just another way to configure for the case described
above.
Im leaving it in the proposal for now, but I will leave it at a low
priority.
> > >
> > > 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.
>
Suggestion:
I can convert over the current CapabilityMap code to a service/object
implementation as part of the work on the profiler.
Eventually, we will make a proposal to Turbine to formally support the
CapabilityMap in the Turbine framework.
> > >
> > > > /*
> > > > 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.
>
Yes, that is exactly what happens in the getProfile method.
The actual contents of what is written in the cookie is implementation
specific.
The storeCookie() can be called by user code when they want to make use of
this service.
> --
> 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]
>
>
--
--------------------------------------------------------------
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]
