> -----Original Message-----
> From: Raphael Luta [mailto:[EMAIL PROTECTED]]
> Sent: Samstag, 4. November 2000 13:15
> To: JetSpeed
> Subject: Re: Portlet API
>
>
....
> > >
> > > - this may create problems with form handling because the
> portal *needs*
> > to
> > > make sure there are no variable name collisions.
> >
> > I'm not sure what exactly you mean - wouldn't different
> forms in different
> > portlets have different targets to which the parameters
> would get posted ?
> >
>
> I'm not sure it's actually possible but if you have a way for a portal
> to implement this I'm definitely interested.
>
Variables/functions:
I also think collisions are really a problem. But they can not just happen
to
variables but also to Javascript functions. As we are mixing up several
different information sources together into one HTML page the probability
that some variables/Javascript functions are named equal is quite high.
I don't think that styleguides are very helpful for this problem, because
very often one wants to include foreign (mostly HTML based) sources/apps
into
the framework, which are not under his control.
We have to prefixing all incoming variables and functions with an GUID.
So there are no collisions and also later it's possible to identify the
source of the variable (--> the related portlet). We have a prototyp
implementation of a porlet, which is handling this stuff using a HTML parser
and a replacement (the problem is: of course you have to replace the
variables
also in all Javascript parts, which are referencing them...).
I think that functionality should later clearly be a feature of the portal
framework, not of the portlet. Only the framework have all informations to
enable such a relation between variables and their sources.
relative URLs
Also we have to rewrite incoming relative URLs. E.g. images are often
relativley
linked (e.g. ../../imageex.jpg), which will clearly not work inside of the
portal.
They have to be substituted with absolute URLs.
Because we just need knowledge about one source this functionality can be
inside
of a portlet (e.g. advanced file server).
links:
If we want to have interactive portlets, we want to have the effect, that
after
e.g. a form-action inside of the portlet is launched not the whole portal is
away, but just the context of the one portlet is replaced by the result.
Therefore
we have to replace links (action, href) with links to the portal. Of course
we have to remember the original location. One way e.g. in the case of forms
would
be to add a new parameter:
<INPUT type="hidden" name="GUID.redirect" value"orginalURL">
Also we have to take care, that all variables are routed to this URL (e.g.
form
parameters).
That should also be a functionality of the portal. We will post a proposal
for this
soon.
Cookies:
The last problem is, that some dynamic sources will use cookies to store
information
in the user's browser. This is not working in the current approach, because
currently
cookies are set against the portal, not the user's browser. Therefore we
have to
take care, that cookies are routed to the browsers by the portal and the
same way
back to the portlet/information source. Another possibility would be to
store them
inside of the session at the portal. Both approaches have advantages and
disadvantages.
This should also be a feature of the portal framework.
Puh, that text is longer as planned, I hope somebody is reading it:-)
Marcus
--
--------------------------------------------------------------
Please read the FAQ! <http://java.apache.org/faq/>
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html>
Problems?: [EMAIL PROTECTED]
