Hi,
On Sep 16, 2010, at 6:26 PM, Howard Lewis Ship wrote:
I'd be interested to know why you are so desperate to enforce this
unique constraint
I am not really desperate... just curious on how one can check and
enforce some properties (or constraints) on the page, its components
and the relationships among them.
I tell you the scenario that motivated the need (that I solve thanks
to the DOM solution #1) of enforcing this uniqueness (or page level
singletoness if you prefer):
The context is to how to integrate T5 and GWT.
I followed the tutorial on the wiki (http://wiki.apache.org/tapestry/Tapestry5GWTIntegration
, BTW the provided jar file is ok while the textual description of the
approach is a bit out-of-date).
The "trick" to embed GWT components in T5 components rely on a T5
component called GwtSupport that provides the right path to the needed
js files
(see the tutorial for the details) and then renders itself as a couple
of tag SCRIPT.
The problem appeared when I started to extend this approach a bit, as
I discovered that this GwtSupport component is mandatory to be in a
page that contains GwtComponents,
but somehow it cannot be duplicate otherwise the GWT Framework (at
least in the hosted mode) generates an exception and does not load the
js files.
So the situation was to somehow check for that constraint.
Now if you take the point of view of a developer that wants to create
a GWT script, (s)he must assume either the GwtSupport is provided or
not, but till the very end (s)he
cannot be sure that the assumption will hold.
So what I tried to do was to factorize the common code of
GwtComponents in a base class containing the GwtSupport component, but
this solved just half of the problem as we
now can safely assume only to have the GwtSupport.
The check for duplication was missing (and this generates my first
question).
I had a similiar problem when I integrated DWR with T5 to provide a
DataPushService using comet, but at that time I only "assumed" that
the supporting
scaffolding of needed-but-not-duplicable components were there as I
expected.
In the meanwhile, I though about possible scenarios to justify an
effort in working on how to enforce/check these properties and I come
up only with few of them:
1) Performance/Non functional constraints. A design time one may want
to limit the presence of some components in the page to prevent server
overload.
2) Affinity/Anti-affinity. A designer may want to have/or to avoid
that two components are rendered in the page at the same time.
3) Licensing. A component cannot be used in more than X pages in the
same app.
BTW, I do not have any personal experience to say if these situations
are worth to be considered or not, and when they make sense.
Thanks.
-- Alessio
PS: @Howard: we can talk about this in London in few weeks.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
