+1 on your writing up a proposal. I remember reading about this on the
Jetspeed list and agree.
> -----Original Message-----
> From: Santiago Gala [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 28, 2000 6:04 AM
> To: Turbine
> Subject: Re: Fwd: [PROPOSAL] Several applications over one Turbine
>
>
>
>
> Shamil Yahin wrote:
>
> > Hello John,
> >
> > Wednesday, September 27, 2000, 10:50:20 PM, you wrote:
> >
> > JM> I just wrote a longer response to your inquiry and my
> email client
> > JM> crashed right before I sent it. So here is a shorter
> version with just
> > JM> a question.
> >
> > JM> Why don't you just rearrange your package structure,
> urls like you give
> > JM> are already allowed:
> >
> > >> http://host:port/zone/Turbine/action/one_package.Login
> > >> http://host:port/zone/Turbine/action/another_package.Login
> >
> > JM> If module.packages=com.company.modules
> >
> > JM> Then put the pieces of the applications into the
> various packages like:
> >
> > JM> com.company.modules.actions.one_package.Login
> > JM> com.company.modules.actions.another_package.Login
> >
> > Yes, this works, but only if you are the owner of all your packages.
> >
> > The reason is that in distributed environment I want modules
> > from different developers to be plugged to the main core.
> > And I can not be sure that 2 different developers will not
> > use the same name in the package name.
> >
> > Therefore we want to take this external modules and assign unique
> > prefix for each of them.
> >
> > The only requirements is that external module developers
> should use some
> > mechanism to get assigned prefix name and use it when making urls:
> >
> > DynamicURI duri = new DynamicURI();
> > duri.setScreen( Prefix.getPrefix() + "MyScreenName" );
> >
>
> I have been experimenting with a similar approach for a
> similar problem, namely
> isolating parameters between different Jetspeed Portlets.
>
> I feel that we should have something like "event" as an
> object. Most of the
> Internal URIs are only used to trigger events (with
> associated actions) in the
> application. The only reasonable way to have isolated namespaces for
> parameters is:
>
> RunData is converted to an interface.
> Current RunData is renamed to TurbineRunData (or something similar)
> the RunDataFactory is adjusted.
> The same process id done with ParameterParser (or else we
> enable extensibility
> by changing several "private" by "protected" ...
> The new DynamicURI() constructor is no longer public.
> Instead, something like
> data.getDynamicURI() should be used to enforce context
> propagation from RunData
> to ParameterParser and DynURI.
> Now this rundata and the associated parameterparser and
> dynamicURI can be used
> to propagate context (generating Portlet/Screen, etc.
> specific instances of
> this trio) so that parameter names are unique and parameters
> are private to a
> given screen/portlet. We could even emulate a
> HttpServletRequest to return
> parameter according to visibility and stripping/adding
> prefixes to ensure
> uniqueness.
>
> It would be even better to be able to tell something like
> event = data.getEvent(); // ---> returning a dynamicURI or similar.
> event.setAction("A");
> event.setParameters(somehash);
> //...
> event.generateURI(); // or a more sophisticated
> event.generateForm(); //having submit and hidden or editable
> parameter
> fields...
>
> Also, the action associated with the event would receive a
> RunData containing
> only visible (direct or inherited) parameters for it...
>
> Then we could choose if the non editable parameters of an
> event are propagated
> as query string parameters, or post parameters, or hidden in
> the session...
>
> This kind of functionality is really essential to Jetspeed,
> to enable for
> instance Turbine Screens or legacy HTML forms as portlets, and several
> instances of the same portlet in a screen.
>
> We could even have a system in which you always generate URIs like
> //server/home/1 (1..n for internal links), and the session
> would map this 1..n
> to the different actions stored in the session.
>
> I wanted to submit this as a proposal here, but I have been too busy
> travelling, etc.
>
> If you think it could be worthwhile, I could restrcture it a
> little bit and
> resend as a proposa (cc Jetspeed list)
>
> >
> > And everything works fine without changing packages structure.
> >
> > / Shamil
> >
> > ------------------------------------------------------------
> > To subscribe: [EMAIL PROTECTED]
> > To unsubscribe: [EMAIL PROTECTED]
> > Search:
<http://www.mail-archive.com/turbine%40list.working-dogs.com/>
> Problems?: [EMAIL PROTECTED]
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
-----------------------------------------------------------------------
This message has been scanned for viruses with Trend Micro's Interscan VirusWall.
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
