eyala at mainsoft.com
Thu Jan 25 09:35:11 EST 2007
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.
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
On Mon, 22 Jan 2007 09:17:40 -0800, "Eyal Alaluf" <eyala at mainsoft.com>
> Hi, Marek and everyone.
> Attached is a diff to improve support for J2EE portlets for the
> TARGET_J2EE configuration. In order to keep the code paths common,
> 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
> assumptions about uniqueness of global variables. The most important
> example is the 'theForm' variable. For Portlet support one cannot
> 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
> 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
> * We save a reference to 'theForm' within the tree view data
> these controls to pass the form to the 'WebForm_DoCallback' function.
> these methods have an extra parameter indicating the form. This means
> code will be broken.
> feature? Unlike the C# API MS does not document these functions and
> tries to abstract their existence in some of System.Web API (e.g. the
> ClientScriptManager class).
remains compatible with MS as far as possible, even though the
doesn't exist for their JS API. The reason for this is that they may
documenting their JS API (the sign of this is the ajax.asp.net stuff,
does include documented JS API which, I imagine, would have to be
the above way when mono includes the implementation of MS AJAX). I think
is another way to work around the theForm problem in JS. I'm assuming
every portlet has its own identifier of some sort and that this
could be used to index a table of theForms from within the JS functions
need to access it. The array can be generated conditionally for
from C# code and its existence checked for inside the JS functions (you
also add a hidden field with a value specifying that the JS is running
mono compiled for TARGET_J2EE. That way all the J2EE specific changes
hidden from the "public" API and the possible future compatibility would
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 17400 bytes
Url : http://lists.ximian.com/pipermail/mono-devel-list/attachments/20070125/c69ff756/attachment.obj
More information about the Mono-devel-list