Marco Romeny wrote:
> 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.
This is one of the reasons why I think that we should have event handling and action
registering capabilities in Jetspeed (maybe even in Turbine).
There are quite a few unique things here:
The page
The URI (including Query string namespace)
The Javascript namespace
...
My idea was to specify (for certain events), that they could be triggered on the
server side
or on the client side. One good example is form validation. If the media is capable,
the
server could render the form with validating Javascript functions to do the validation
at
the browser. If the media does not have scripting capabilities, all form fields would
be
validated back at the server.
>
> 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.
Can you be more specific?
I have very little time and a lot of bugs to fix.
I think I could try to fix it, but I would need more specific help.
>
> 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]
--
--------------------------------------------------------------
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]
