another important thing is javascript events.
a lot of code normally has a need to be run not
until the page has loaded, ie. onload="" / window.onload
and there is only one event.
I once wrote a function popToFunc(code) which would
append a javascript code (if string) or function to an
existing/non-existing function.
function popToFunc(funcdesc,code){
if(!eval('window.'+funcdesc)) eval('window.'+funcdesc +'=function (){\na=1}');
func=eval('window.'+funcdesc).toString();
eval('window.'+funcdesc+'='+func.replace(/function
\w*\(([\s\w,]*)\).*\{([\W\s\w]*)\}/g,
'function
($1){$2\n'+(typeof(code)=='function'?code+'()':code)+';\n}'));
}
use:
popToFunc('hello','alert(3)');
hello(); --> alerts 3
popToFunc('hello','alert(4)');
hello(); --> alerts 3, alerts 4
popToFunc('hello',function (){alert(5)}); // good if you dont want to escape all you
do
hello(); --> alerts 3, alerts 4, alerts 5
popToFunc('hello',hello);
hello(); --> alerts 3, alerts 4, alerts 5, alerts 3, alerts 4, alerts 5
haven't tested it throughly, but this would resolve the problems with the
customizer i think.
Add Function.prototype.append=function (code){popToFunc(this.toString(),code)}
and you can use hello.append('alert(6)') which looks nicer. make sure hello exists...
/m
"Schwarz, Marcus" wrote:
>
> > -----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]
