> Puh, that text is longer as planned, I hope somebody is reading it:-)
Marcus, don't worry I read it all and Im thankful i did....
Your discussion is very relevant to some of the problems I am experiencing.
My portal is aggregating web pages from several different sources, and
frequently from the same company's intranet where they seem to reuse
stylesheets and scripts, but they make minor changes to them (i believe this
is called the cut&paste antipattern which seems to be prevalent these days).
So yes, you are describing a real headache for me right now.
These pages each have their own <HTML><HEAD><TITLE> and within the <HEAD>
they each have their own cascading stylesheets and scripts. In an open,
api-based environment, I am not sure how the API can address these kinds of
collision problems. As Thomas Schaeck stated, guidelines
"How-to-write-portlets Guide" may be necessary. One guideline may be for
scripts and stylesheets to always be stored in separate files, perhaps some
kind of registration of these resources could be formalised and requested by
the portal before requesting the content of each portlet.
In any case, much of the content that I am working most always comes from
pre-existing sources, and I always need to edit it, rewrite urls etc, before
incorporating it in the portal.
-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Schwarz, Marcus
Sent: Sunday, November 05, 2000 12:21 PM
To: 'JetSpeed'
Subject: RE: Portlet API
> -----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]
--
--------------------------------------------------------------
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]
