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]
