[Mono-dev] [Mono-Dev]: Modifications to System.Web javascript for J2EE portal support

[Eyal Alaluf]

Hi, Marek & all.

Following up on our discussion attached a new patch with minimal changes
to JS API that goes according to the following guide lines
  1. Whenever possible use the ctrl hierarchy to find the form
containing the ctrl
  2. When the method is attached to the form (e.g. 
WebForm_SaveScrollPositionSubmit) use this as the form.
  3. When all else fails append a new parameter to the function. Pass
the form as this param. In the function if the param is not defined use
'theForm'. Thus we still support invoking the function as before.

Any comments are welcome.

Eyal.

-----Original Message-----
From: Marek Habersack [mailto:grendello at gmail.com] 
Sent: 22 January 2007 20:40
To: Eyal Alaluf
Cc: mono-devel-list at lists.ximian.com
Subject: Re: [Mono-Dev]: Modifications to System.Web javascript for J2EE
portal support

On Mon, 22 Jan 2007 09:17:40 -0800, "Eyal Alaluf" <eyala at mainsoft.com>
scribbled:

> Hi, Marek and everyone.
Hello Eyal,

> Attached is a diff to improve support for J2EE portlets for the
> TARGET_J2EE configuration. In order to keep the code paths common,
most
> of the diff is not under '#if TARGET_j2EE'. Therefore I'd like you to
> review and approve it before I can commit.
> 
> The main issue stems from the fact that portlets in J2EE render HTML
> fragments and not the whole page. That is one page can contain several
> portlets and therefore several ASP.Net pages. This breaks implicit
code
> assumptions about uniqueness of global variables. The most important
> example is the 'theForm' variable. For Portlet support one cannot
assume
> that on the client side there is exactly one 'theForm' defined.
> 
> The changes common with Mono are:
> 
> *        An internal property called 'theForm' is added to
> System.Web.UI.Page. Its value for TARGET_J2EE will be different for
> every portlet.
This is fine

> *        We pass the 'theForm' as a parameter to all the JavaScript
> functions that use it directly.
> 
> a.    In cases of callback functions (like functions assigned to
> window.onload) we create a function whose name depends upon the
portlet
> namespace and that passes 'theForm' to the global JavaScript function.
> 
> *        We save a reference to 'theForm' within the tree view data
> (also in details view and grid view data). This allows the JavaScript
of
> these controls to pass the form to the 'WebForm_DoCallback' function.
> 
> It is important to note that before this change some key JavaScript
> functions were compatible with MS JavaScript functions. After the
change
> these methods have an extra parameter indicating the form. This means
> that if someone used such a function from his JavaScript code then his
> code will be broken. 
> 
> Do you think that being compatible with MS on JavaScript is an
important
> feature? Unlike the C# API MS does not document these functions and
even
> tries to abstract their existence in some of System.Web API (e.g. the
> ClientScriptManager class).
As for the above changes I personally would prefer that the JavaScript
code
remains compatible with MS as far as possible, even though the
documentation
doesn't exist for their JS API. The reason for this is that they may
start
documenting their JS API (the sign of this is the ajax.asp.net stuff,
which
does include documented JS API which, I imagine, would have to be
modified in
the above way when mono includes the implementation of MS AJAX). I think
there
is another way to work around the theForm problem in JS. I'm assuming
that
every portlet has its own identifier of some sort and that this
identifier
could be used to index a table of theForms from within the JS functions
that
need to access it. The array can be generated conditionally for
TARGET_J2EE
from C# code and its existence checked for inside the JS functions (you
could
also add a hidden field with a value specifying that the JS is running
under
mono compiled for TARGET_J2EE. That way all the J2EE specific changes
would be
hidden from the "public" API and the possible future compatibility would
be
preserved.

best regards,

marek
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Portal.jscript.diff
Type: application/octet-stream
Size: 17400 bytes
Desc: Portal.jscript.diff
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070125/c69ff756/attachment.obj