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

[Marek Habersack]

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: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070122/324f7b04/attachment.bin