You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Drew McAuliffe <dr...@lowerunit.com> on 2004/04/15 03:23:08 UTC
Dynamic component binding
I'm just starting to delve into Tapestry, so if there's something I've
missed so far in answer to this question, I apologize in advance.
Here's my question: Is it possible, when Tapestry is loaded, to have some
mechanism of dynamically loading components in such a way that they can
decorate other components? What I'm basically looking to do is something
similar to the way eclipse plugins work, but in the web world. In the
eclipse runtime, a plugin declares extension points. Another plugin declares
that it is extending those extension points. I'm trying to see if there's a
way to do the same thing in a web application, and thus far, Tapestry seems
to offer the most promise.
As an example, imagine "SomePageA" is a component declares an extension
point called "tabs". Another component, "ExtensionB", wants to extend that
page, specifically by adding a new tab to the "tabs" extension point. In
practice, this would mean that a user would see a new tab on the page.
The problem with most web applications, or other kinds of apps that don't
use a dynamic plugin discovery runtime like eclipse, is that to get that new
tab in the original page, you have to couple the components "SomePageA" and
"ExtensionB" together, explicitly wiring them. Tapestry seems to work the
same, so you would have to modify the page specification in "SomePageA" to
add the new tab.
What I would like to do is to limit the dependency so that the "SomePageA"
component can be packaged and deployed completely separately from
"ExtensionB" and wouldn't need to be modified if "ExtensionB" were used.
Something would have to load up "ExtensionB", see that it has an extension
for the "tabs" extension point on "SomePageA", and dynamically bind it into
the "SomePageA" component, displaying as a new tabbed page. Again, the key
is that both components can be packaged completely separately, and
"SomePageA" doesn't have to know anything at all about any extensions.
Does this sound possible? Is this something that someone else has played
around with? I think this could be an incredibly useful feature. I'm hoping
that Tapestry's component-based nature would make this more possible than it
would be with other frameworks. If it is, you could feasibly create a set of
web-specific plugins, and arrange them as necessary to build applications,
just like you see happening in Eclipse (where the workbench gets extended to
provide all kinds of useful functionality-- like Spindle!).
Thanks,
Drew
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic component binding
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
I'll stick with your concrete example... most definitely yes, a page
definitely could be alerted from its nested components of new
capabilities. For example, the @Body component is notified when
components need to inject some JavaScript and such... look at the
DatePicker and how it does Body.get.
Nothing gives you this capability for free, but nothing prevents you
from making a Border component, for example, be alerted when smart
nested components need to tell it something.
I'd love to hear more about how you pull this type of thing off - a
slick idea indeed.
Erik
On Apr 14, 2004, at 9:23 PM, Drew McAuliffe wrote:
> I'm just starting to delve into Tapestry, so if there's something I've
> missed so far in answer to this question, I apologize in advance.
>
> Here's my question: Is it possible, when Tapestry is loaded, to have
> some
> mechanism of dynamically loading components in such a way that they can
> decorate other components? What I'm basically looking to do is
> something
> similar to the way eclipse plugins work, but in the web world. In the
> eclipse runtime, a plugin declares extension points. Another plugin
> declares
> that it is extending those extension points. I'm trying to see if
> there's a
> way to do the same thing in a web application, and thus far, Tapestry
> seems
> to offer the most promise.
>
> As an example, imagine "SomePageA" is a component declares an extension
> point called "tabs". Another component, "ExtensionB", wants to extend
> that
> page, specifically by adding a new tab to the "tabs" extension point.
> In
> practice, this would mean that a user would see a new tab on the page.
>
> The problem with most web applications, or other kinds of apps that
> don't
> use a dynamic plugin discovery runtime like eclipse, is that to get
> that new
> tab in the original page, you have to couple the components
> "SomePageA" and
> "ExtensionB" together, explicitly wiring them. Tapestry seems to work
> the
> same, so you would have to modify the page specification in
> "SomePageA" to
> add the new tab.
>
> What I would like to do is to limit the dependency so that the
> "SomePageA"
> component can be packaged and deployed completely separately from
> "ExtensionB" and wouldn't need to be modified if "ExtensionB" were
> used.
> Something would have to load up "ExtensionB", see that it has an
> extension
> for the "tabs" extension point on "SomePageA", and dynamically bind it
> into
> the "SomePageA" component, displaying as a new tabbed page. Again, the
> key
> is that both components can be packaged completely separately, and
> "SomePageA" doesn't have to know anything at all about any extensions.
>
> Does this sound possible? Is this something that someone else has
> played
> around with? I think this could be an incredibly useful feature. I'm
> hoping
> that Tapestry's component-based nature would make this more possible
> than it
> would be with other frameworks. If it is, you could feasibly create a
> set of
> web-specific plugins, and arrange them as necessary to build
> applications,
> just like you see happening in Eclipse (where the workbench gets
> extended to
> provide all kinds of useful functionality-- like Spindle!).
>
> Thanks,
>
> Drew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: ValidField Form focus
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
I would suggest adding a little Script to override the focusing that the ValidField does. A very,
very quick eyed user might see the cursor jump from one field to the next. Not elegant, but
pragmatic.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Eric Schneider [mailto:eric@centralparksoftware.com]
> Sent: Thursday, April 15, 2004 9:47 AM
> To: Tapestry users
> Subject: Re: ValidField Form focus
>
>
> Erik,
>
> Thanks for looking into this. I guess I'll go for writing
> the ValidField
> wrapper.
>
> > The tougher question is what to do now? I'm not sure. Maybe simply
> > getting rid of the isRequired check would do the trick?
>
> I'm not really sure either. I'm just trying to think of a
> case where you
> would want the focus to anything but the first field (aside
> from when the
> IValidationDelegate has errors). Hmmmm.
>
> e.
>
> ----- Original Message -----
> From: "Erik Hatcher" <er...@ehatchersolutions.com>
> To: "Tapestry users" <ta...@jakarta.apache.org>
> Sent: Wednesday, April 14, 2004 11:08 PM
> Subject: Re: ValidField Form focus
>
>
> > On Apr 14, 2004, at 10:40 PM, Eric Schneider wrote:
> > > Quick ValidationDelegate question. If I have a form that contains
> > > ValidField components using StringValidators.....why
> isn't the first
> > > form
> > > field focused on page load if the validaor required
> attribute is set to
> > > false?
> > >
> > > <bean name="stringValidator" lifecycle="render"
> > > class="org.apache.tapestry.valid.StringValidator">
> > > <set-property name="required" expression="false"/>
> > > <set-property name="minimumLength" expression="3"/>
> > > <set-property name="clientScriptingEnabled" expression="true"/>
> > > </bean>
> > >
> > > Is there a way to override that behavior? I'd like the
> first field in
> > > the
> > > form to have the focus if it is required or not.
> >
> > I love questions like this.... I like digging (and it took a bit) to
> > find answers. The culprit is ValidField.readValue()
> >
> > if (Tapestry.isBlank(result) &&
> getValidator().isRequired())
> > addSelect(getPage().getRequestCycle());
> >
> > addSelect is what adds JavaScript to onload for focus to be
> set. So,
> > at this time there isn't a way to override this behavior.
> >
> > The tougher question is what to do now? I'm not sure. Maybe simply
> > getting rid of the isRequired check would do the trick?
> >
> > You could write your own ValidField wrapper that could do the same
> > thing that happens under addSelect() (Body.get....
> > body.addInitializationScript...) which would surely do the trick.
> >
> > Oh, and if I'm off base, correct me.
> >
> > Erik
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: ValidField Form focus
Posted by Eric Schneider <er...@centralparksoftware.com>.
Erik,
Thanks for looking into this. I guess I'll go for writing the ValidField
wrapper.
> The tougher question is what to do now? I'm not sure. Maybe simply
> getting rid of the isRequired check would do the trick?
I'm not really sure either. I'm just trying to think of a case where you
would want the focus to anything but the first field (aside from when the
IValidationDelegate has errors). Hmmmm.
e.
----- Original Message -----
From: "Erik Hatcher" <er...@ehatchersolutions.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
Sent: Wednesday, April 14, 2004 11:08 PM
Subject: Re: ValidField Form focus
> On Apr 14, 2004, at 10:40 PM, Eric Schneider wrote:
> > Quick ValidationDelegate question. If I have a form that contains
> > ValidField components using StringValidators.....why isn't the first
> > form
> > field focused on page load if the validaor required attribute is set to
> > false?
> >
> > <bean name="stringValidator" lifecycle="render"
> > class="org.apache.tapestry.valid.StringValidator">
> > <set-property name="required" expression="false"/>
> > <set-property name="minimumLength" expression="3"/>
> > <set-property name="clientScriptingEnabled" expression="true"/>
> > </bean>
> >
> > Is there a way to override that behavior? I'd like the first field in
> > the
> > form to have the focus if it is required or not.
>
> I love questions like this.... I like digging (and it took a bit) to
> find answers. The culprit is ValidField.readValue()
>
> if (Tapestry.isBlank(result) && getValidator().isRequired())
> addSelect(getPage().getRequestCycle());
>
> addSelect is what adds JavaScript to onload for focus to be set. So,
> at this time there isn't a way to override this behavior.
>
> The tougher question is what to do now? I'm not sure. Maybe simply
> getting rid of the isRequired check would do the trick?
>
> You could write your own ValidField wrapper that could do the same
> thing that happens under addSelect() (Body.get....
> body.addInitializationScript...) which would surely do the trick.
>
> Oh, and if I'm off base, correct me.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: ValidField Form focus
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
We could maybe juggle that code out of ValidField and into ValidationDelegate in such a way that it
can be overridden for cases such as these.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Erik Hatcher [mailto:erik@ehatchersolutions.com]
> Sent: Wednesday, April 14, 2004 11:09 PM
> To: Tapestry users
> Subject: Re: ValidField Form focus
>
>
> On Apr 14, 2004, at 10:40 PM, Eric Schneider wrote:
> > Quick ValidationDelegate question. If I have a form that contains
> > ValidField components using StringValidators.....why isn't
> the first
> > form
> > field focused on page load if the validaor required
> attribute is set to
> > false?
> >
> > <bean name="stringValidator" lifecycle="render"
> > class="org.apache.tapestry.valid.StringValidator">
> > <set-property name="required" expression="false"/>
> > <set-property name="minimumLength" expression="3"/>
> > <set-property name="clientScriptingEnabled" expression="true"/>
> > </bean>
> >
> > Is there a way to override that behavior? I'd like the
> first field in
> > the
> > form to have the focus if it is required or not.
>
> I love questions like this.... I like digging (and it took a bit) to
> find answers. The culprit is ValidField.readValue()
>
> if (Tapestry.isBlank(result) && getValidator().isRequired())
> addSelect(getPage().getRequestCycle());
>
> addSelect is what adds JavaScript to onload for focus to be set. So,
> at this time there isn't a way to override this behavior.
>
> The tougher question is what to do now? I'm not sure. Maybe simply
> getting rid of the isRequired check would do the trick?
>
> You could write your own ValidField wrapper that could do the same
> thing that happens under addSelect() (Body.get....
> body.addInitializationScript...) which would surely do the trick.
>
> Oh, and if I'm off base, correct me.
>
> Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: ValidField Form focus
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 14, 2004, at 10:40 PM, Eric Schneider wrote:
> Quick ValidationDelegate question. If I have a form that contains
> ValidField components using StringValidators.....why isn't the first
> form
> field focused on page load if the validaor required attribute is set to
> false?
>
> <bean name="stringValidator" lifecycle="render"
> class="org.apache.tapestry.valid.StringValidator">
> <set-property name="required" expression="false"/>
> <set-property name="minimumLength" expression="3"/>
> <set-property name="clientScriptingEnabled" expression="true"/>
> </bean>
>
> Is there a way to override that behavior? I'd like the first field in
> the
> form to have the focus if it is required or not.
I love questions like this.... I like digging (and it took a bit) to
find answers. The culprit is ValidField.readValue()
if (Tapestry.isBlank(result) && getValidator().isRequired())
addSelect(getPage().getRequestCycle());
addSelect is what adds JavaScript to onload for focus to be set. So,
at this time there isn't a way to override this behavior.
The tougher question is what to do now? I'm not sure. Maybe simply
getting rid of the isRequired check would do the trick?
You could write your own ValidField wrapper that could do the same
thing that happens under addSelect() (Body.get....
body.addInitializationScript...) which would surely do the trick.
Oh, and if I'm off base, correct me.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
ValidField Form focus
Posted by Eric Schneider <er...@centralparksoftware.com>.
Hi,
Quick ValidationDelegate question. If I have a form that contains
ValidField components using StringValidators.....why isn't the first form
field focused on page load if the validaor required attribute is set to
false?
<bean name="stringValidator" lifecycle="render"
class="org.apache.tapestry.valid.StringValidator">
<set-property name="required" expression="false"/>
<set-property name="minimumLength" expression="3"/>
<set-property name="clientScriptingEnabled" expression="true"/>
</bean>
Is there a way to override that behavior? I'd like the first field in the
form to have the focus if it is required or not.
Thanks
Eric
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Dynamic component binding
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
On Apr 14, 2004, at 10:32 PM, Howard M. Lewis Ship wrote:
> HiveMind is going to provide a new infrastructure for Tapestry 3.1. I
> think of it as kind of
> information soup, that should allow some or all of the things you're
> discussing to be implemented.
Information soup, huh? You're really tight with the Apple analogies,
eh? Tapestry/WO. Now "soup" - which is the term the Apple Newton used
for its data storage - everything is connected between "apps" on the
Newton through overlapping metadata - super elegantly.
Hmmmmm..... I'm thinking differently.
Erik
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Dynamic component binding
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> Part of the trouble I'm trying to address is how to allow
> plugins to be
> dropped in with their extension information, so that the host
> application
> doesn't have to have its configuration files edited. From
> what I can tell of
> HiveMind, to wire in extensions to extension points, I modify
> the master
> HiveMind registry. I'd prefer an eclipse-style plugin, where
> the host is
> oblivious to its plugins, and the plugins contain a
> "manifest" of sorts that
> determine how the runtime decorates the hosts with their
> extensions. Am I
> wrong in this assessment of HiveMind? Again, my knowledge of
> it is very
> limited at this point. Eventually, it would be nice, though
> difficult, to
> use the Eclipse PDE features to actually handle the wiring.
> This could be
> translated by some layer on top of HiveMind to allow things
> to be autowired.
> The PDE features would make the plugin development much easier, and, I
> believe, would also result in OSGI-compliant plugins (which might make
> integration with other systems easier as well).
>
There's no master registry in HiveMind ... that's the whole points; it's style very strongly after
Eclipse plugins, with a services model put in for good measure. However, is organized to suite a
J2EE environment, either as WAR or EAR type deployment. Instead of hot deployment, it really relies
on an undeploy EVERYTHING restart approach, as part of redeployment of an WAR or EAR.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Dynamic component binding
Posted by Drew McAuliffe <dr...@lowerunit.com>.
Thanks for the info. The HiveMind example looks interesting. I'm still in
the process of investigating whether or not what I want to do is actually
achievable, and which tools will help the most. I'm becoming more and more
convinced that Tapestry will have a much better chance of doing what I want
than any other framework.
This is all sort of up in the air and in mental prototyping stages, but what
I'd eventually like to do is provide some sort of OSGI-/Eclipse-style
mechanism of deploying pluggable application components. This would allow
for a great deal of reuse of functionality built for clients, at a level of
abstraction a little higher than typical uses of the word "component". For
example, to most, a component is something like a date-picker. I'm looking
for a bigger idea, like a "project management system" or a "change tracking
system", which could be plugged together like Eclipse plugins to build a
complete system. Eclipse has given me hope that it can be done (unlike EJB
promises), and now my challenge is trying to figure out how to do it in a
web application.
Part of the trouble I'm trying to address is how to allow plugins to be
dropped in with their extension information, so that the host application
doesn't have to have its configuration files edited. From what I can tell of
HiveMind, to wire in extensions to extension points, I modify the master
HiveMind registry. I'd prefer an eclipse-style plugin, where the host is
oblivious to its plugins, and the plugins contain a "manifest" of sorts that
determine how the runtime decorates the hosts with their extensions. Am I
wrong in this assessment of HiveMind? Again, my knowledge of it is very
limited at this point. Eventually, it would be nice, though difficult, to
use the Eclipse PDE features to actually handle the wiring. This could be
translated by some layer on top of HiveMind to allow things to be autowired.
The PDE features would make the plugin development much easier, and, I
believe, would also result in OSGI-compliant plugins (which might make
integration with other systems easier as well).
All pie in the sky for now. Thought it might be interesting. And I would be
interested in your rates, though I don't know when I would need assistance.
Probably sometime this summer when things die down with some clients.
Thanks again for the info,
Drew
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Thursday, April 15, 2004 3:25 PM
To: 'Tapestry users'
Subject: RE: Dynamic component binding
> -----Original Message-----
> From: Drew McAuliffe [mailto:drew@lowerunit.com]
> Sent: Thursday, April 15, 2004 5:52 PM
> To: 'Tapestry users'
> Subject: RE: Dynamic component binding
>
>
> How do you envision HiveMind doing what I proposed? I've investigated
> HiveMind somewhat. From what I can tell, it looks to provide
> competition to the Spring platform. I haven't committed to HiveMind
> for my own dev,
Cooperatition perhaps? Different sensibilities, different developers,
different implementations.
Eight months ago I didn't say "What can I build that's like Spring only
better?"; I had a specific set of requirements that set me in a particular
direction, and its just been feeding of itself.
> but I'm
> interested in it, since I like its preference for interfaces over the
> way Spring handles things (and I abhor the word "bean" for describing
> anything; as much as I'm scared by a name like "HiveMind", referring
> to anything and everything as a "bean" just pisses me off. Who outside
> of Sun's marketing department thinks a "bean" has any real intrisic
> meaning beyond coffee and lentils?).
My wife loves the name. So it's staying!
>
> What I caught a hint of, but am unsure of, is HiveMind's capacity for
> autowiring things in a fashion similar to Eclipse. It seems the
> potential is there, with mention of things like extensions and
> extension points, but I haven't been able to uncover the details.
> Exactly what sort of facility is in hivemind now for this, and what is
> planned in the future?
Let's try a concrete example: you application may have a navigational
toolbar.
Much like the toolbar in the Eclipse UI, different modules within the
application may have different contributions to make to the toolbar.
So, for this I see two things:
1) One (or more) <extension-point>s within HiveMind that define what items
appear on the toolbar, under what circumstances, and what those items do
when they are activated, etc.
2) Custom Tapestry components that work with the HiveMind extension points
(or more likely, through a HiveMind service that has access to the extension
point). So the component asks the service:
"What's on the toolbar right now?" and the component renders it out. Most
likely, links generated by the component will call into listener methods of
the component that become callbacks through HiveMind to the rest of the
application.
If you check out some of the examples for HiveMind, you can see that this
infrastructure is already in place.
http://jakarta.apache.org/hivemind/case1.html
If you find this vague ... sorry. Only so much I can do via e-mail and in a
lack of specifics. But if you want to do some real brainstorming ... my
rates are very reasonable. Seriously, consulting (Tapestry, HiveMind, J2EE)
is what I do.
>
> Also, how does this tie into Tapestry? I'm curious as to what
> improvements the Tapestry/Hivemind integration is expected to bring,
> and in specifically how (in a general sense) it can help me achieve
> the design I proposed.
The integration will make it much easier to override the different Tapestry
subsystems, which will be HiveMind services. In addition, the work to
implement Tapestry using HiveMind will "wear a groove" in HiveMind,
identifying any rough edges. A lot of the infrastructure you'll need in a
real application will come out of HiveMind: things like simple task
scheduling, and some thread isolation stuff.
>
> I'm midway through the Tapestry book and I'm eager to get a Tapestry
> app out the door. So far, I like what I see. Thanks!
That's what I like to hear.
>
> Drew
>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: Wednesday, April 14, 2004 7:33 PM
> To: 'Tapestry users'
> Subject: RE: Dynamic component binding
>
> Quick man, get the to http://jakarta.apache.org/hivemind/
>
> HiveMind is going to provide a new infrastructure for Tapestry 3.1. I
> think of it as kind of information soup, that should allow some or all
> of the things you're discussing to be implemented.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant Creator,
> Tapestry: Java Web
> Components Creator, HiveMind http://howardlewisship.com
>
>
> > -----Original Message-----
> > From: Drew McAuliffe [mailto:drew@lowerunit.com]
> > Sent: Wednesday, April 14, 2004 9:23 PM
> > To: tapestry-user@jakarta.apache.org
> > Subject: Dynamic component binding
> >
> >
> > I'm just starting to delve into Tapestry, so if there's
> something I've
> > missed so far in answer to this question, I apologize in advance.
> >
> > Here's my question: Is it possible, when Tapestry is loaded, to have
> > some mechanism of dynamically loading components in such a way that
> > they can decorate other components? What I'm basically looking to do
> > is something similar to the way eclipse plugins work, but in the web
> world. In the
> > eclipse runtime, a plugin declares extension points. Another plugin
> > declares that it is extending those extension points. I'm trying to
> > see if there's a way to do the same thing in a web application, and
> > thus far, Tapestry seems to offer the most promise.
> >
> > As an example, imagine "SomePageA" is a component declares an
> > extension point called "tabs". Another component, "ExtensionB",
> > wants to extend that page, specifically by adding a new tab to the
> > "tabs"
> > extension point. In
> > practice, this would mean that a user would see a new tab
> on the page.
> >
> > The problem with most web applications, or other kinds of
> > apps that don't
> > use a dynamic plugin discovery runtime like eclipse, is that
> > to get that new
> > tab in the original page, you have to couple the components
> > "SomePageA" and
> > "ExtensionB" together, explicitly wiring them. Tapestry seems
> > to work the
> > same, so you would have to modify the page specification in
> > "SomePageA" to
> > add the new tab.
> >
> > What I would like to do is to limit the dependency so that
> > the "SomePageA"
> > component can be packaged and deployed completely separately from
> > "ExtensionB" and wouldn't need to be modified if "ExtensionB"
> > were used.
> > Something would have to load up "ExtensionB", see that it has
> > an extension
> > for the "tabs" extension point on "SomePageA", and
> > dynamically bind it into
> > the "SomePageA" component, displaying as a new tabbed page.
> > Again, the key
> > is that both components can be packaged completely separately, and
> > "SomePageA" doesn't have to know anything at all about any
> extensions.
> >
> > Does this sound possible? Is this something that someone else
> > has played
> > around with? I think this could be an incredibly useful
> > feature. I'm hoping
> > that Tapestry's component-based nature would make this more
> > possible than it
> > would be with other frameworks. If it is, you could feasibly
> > create a set of
> > web-specific plugins, and arrange them as necessary to build
> > applications,
> > just like you see happening in Eclipse (where the workbench
> > gets extended to
> > provide all kinds of useful functionality-- like Spindle!).
> >
> > Thanks,
> >
> > Drew
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Dynamic component binding
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
> -----Original Message-----
> From: Drew McAuliffe [mailto:drew@lowerunit.com]
> Sent: Thursday, April 15, 2004 5:52 PM
> To: 'Tapestry users'
> Subject: RE: Dynamic component binding
>
>
> How do you envision HiveMind doing what I proposed? I've investigated
> HiveMind somewhat. From what I can tell, it looks to provide
> competition to
> the Spring platform. I haven't committed to HiveMind for my
> own dev,
Cooperatition perhaps? Different sensibilities, different developers, different implementations.
Eight months ago I didn't say "What can I build that's like Spring only better?"; I had a specific
set of requirements that set me in a particular direction, and its just been feeding of itself.
> but I'm
> interested in it, since I like its preference for interfaces
> over the way
> Spring handles things (and I abhor the word "bean" for
> describing anything;
> as much as I'm scared by a name like "HiveMind", referring to
> anything and
> everything as a "bean" just pisses me off. Who outside of
> Sun's marketing
> department thinks a "bean" has any real intrisic meaning
> beyond coffee and
> lentils?).
My wife loves the name. So it's staying!
>
> What I caught a hint of, but am unsure of, is HiveMind's capacity for
> autowiring things in a fashion similar to Eclipse. It seems
> the potential is
> there, with mention of things like extensions and extension
> points, but I
> haven't been able to uncover the details. Exactly what sort
> of facility is
> in hivemind now for this, and what is planned in the future?
Let's try a concrete example: you application may have a navigational toolbar.
Much like the toolbar in the Eclipse UI, different modules within the application may
have different contributions to make to the toolbar.
So, for this I see two things:
1) One (or more) <extension-point>s within HiveMind that define what items appear on the toolbar,
under what circumstances, and what those items do when they are activated, etc.
2) Custom Tapestry components that work with the HiveMind extension points (or more likely, through
a HiveMind service that has access to the extension point). So the component asks the service:
"What's on the toolbar right now?" and the component renders it out. Most likely, links generated
by the component will call into listener methods of the component that become callbacks through
HiveMind to the rest of the application.
If you check out some of the examples for HiveMind, you can see that this infrastructure is already
in place. http://jakarta.apache.org/hivemind/case1.html
If you find this vague ... sorry. Only so much I can do via e-mail and in a lack of specifics. But
if you want to do some real brainstorming ... my rates are very reasonable. Seriously, consulting
(Tapestry, HiveMind, J2EE) is what I do.
>
> Also, how does this tie into Tapestry? I'm curious as to what
> improvements
> the Tapestry/Hivemind integration is expected to bring, and
> in specifically
> how (in a general sense) it can help me achieve the design I proposed.
The integration will make it much easier to override the different Tapestry subsystems, which will
be HiveMind services. In addition, the work to implement Tapestry using HiveMind will "wear a
groove" in HiveMind, identifying any rough edges. A lot of the infrastructure you'll need in a real
application will come out of HiveMind: things like simple task scheduling, and some thread isolation
stuff.
>
> I'm midway through the Tapestry book and I'm eager to get a
> Tapestry app out
> the door. So far, I like what I see. Thanks!
That's what I like to hear.
>
> Drew
>
> -----Original Message-----
> From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
> Sent: Wednesday, April 14, 2004 7:33 PM
> To: 'Tapestry users'
> Subject: RE: Dynamic component binding
>
> Quick man, get the to http://jakarta.apache.org/hivemind/
>
> HiveMind is going to provide a new infrastructure for
> Tapestry 3.1. I think
> of it as kind of information soup, that should allow some or
> all of the
> things you're discussing to be implemented.
>
> --
> Howard M. Lewis Ship
> Independent J2EE / Open-Source Java Consultant Creator,
> Tapestry: Java Web
> Components Creator, HiveMind http://howardlewisship.com
>
>
> > -----Original Message-----
> > From: Drew McAuliffe [mailto:drew@lowerunit.com]
> > Sent: Wednesday, April 14, 2004 9:23 PM
> > To: tapestry-user@jakarta.apache.org
> > Subject: Dynamic component binding
> >
> >
> > I'm just starting to delve into Tapestry, so if there's
> something I've
> > missed so far in answer to this question, I apologize in advance.
> >
> > Here's my question: Is it possible, when Tapestry is loaded,
> > to have some
> > mechanism of dynamically loading components in such a way
> > that they can
> > decorate other components? What I'm basically looking to do
> > is something
> > similar to the way eclipse plugins work, but in the web
> world. In the
> > eclipse runtime, a plugin declares extension points. Another
> > plugin declares
> > that it is extending those extension points. I'm trying to
> > see if there's a
> > way to do the same thing in a web application, and thus far,
> > Tapestry seems
> > to offer the most promise.
> >
> > As an example, imagine "SomePageA" is a component declares an
> > extension
> > point called "tabs". Another component, "ExtensionB", wants
> > to extend that
> > page, specifically by adding a new tab to the "tabs"
> > extension point. In
> > practice, this would mean that a user would see a new tab
> on the page.
> >
> > The problem with most web applications, or other kinds of
> > apps that don't
> > use a dynamic plugin discovery runtime like eclipse, is that
> > to get that new
> > tab in the original page, you have to couple the components
> > "SomePageA" and
> > "ExtensionB" together, explicitly wiring them. Tapestry seems
> > to work the
> > same, so you would have to modify the page specification in
> > "SomePageA" to
> > add the new tab.
> >
> > What I would like to do is to limit the dependency so that
> > the "SomePageA"
> > component can be packaged and deployed completely separately from
> > "ExtensionB" and wouldn't need to be modified if "ExtensionB"
> > were used.
> > Something would have to load up "ExtensionB", see that it has
> > an extension
> > for the "tabs" extension point on "SomePageA", and
> > dynamically bind it into
> > the "SomePageA" component, displaying as a new tabbed page.
> > Again, the key
> > is that both components can be packaged completely separately, and
> > "SomePageA" doesn't have to know anything at all about any
> extensions.
> >
> > Does this sound possible? Is this something that someone else
> > has played
> > around with? I think this could be an incredibly useful
> > feature. I'm hoping
> > that Tapestry's component-based nature would make this more
> > possible than it
> > would be with other frameworks. If it is, you could feasibly
> > create a set of
> > web-specific plugins, and arrange them as necessary to build
> > applications,
> > just like you see happening in Eclipse (where the workbench
> > gets extended to
> > provide all kinds of useful functionality-- like Spindle!).
> >
> > Thanks,
> >
> > Drew
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail:
> tapestry-user-help@jakarta.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Dynamic component binding
Posted by Drew McAuliffe <dr...@lowerunit.com>.
How do you envision HiveMind doing what I proposed? I've investigated
HiveMind somewhat. From what I can tell, it looks to provide competition to
the Spring platform. I haven't committed to HiveMind for my own dev, but I'm
interested in it, since I like its preference for interfaces over the way
Spring handles things (and I abhor the word "bean" for describing anything;
as much as I'm scared by a name like "HiveMind", referring to anything and
everything as a "bean" just pisses me off. Who outside of Sun's marketing
department thinks a "bean" has any real intrisic meaning beyond coffee and
lentils?).
What I caught a hint of, but am unsure of, is HiveMind's capacity for
autowiring things in a fashion similar to Eclipse. It seems the potential is
there, with mention of things like extensions and extension points, but I
haven't been able to uncover the details. Exactly what sort of facility is
in hivemind now for this, and what is planned in the future?
Also, how does this tie into Tapestry? I'm curious as to what improvements
the Tapestry/Hivemind integration is expected to bring, and in specifically
how (in a general sense) it can help me achieve the design I proposed.
I'm midway through the Tapestry book and I'm eager to get a Tapestry app out
the door. So far, I like what I see. Thanks!
Drew
-----Original Message-----
From: Howard M. Lewis Ship [mailto:hlship@comcast.net]
Sent: Wednesday, April 14, 2004 7:33 PM
To: 'Tapestry users'
Subject: RE: Dynamic component binding
Quick man, get the to http://jakarta.apache.org/hivemind/
HiveMind is going to provide a new infrastructure for Tapestry 3.1. I think
of it as kind of information soup, that should allow some or all of the
things you're discussing to be implemented.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant Creator, Tapestry: Java Web
Components Creator, HiveMind http://howardlewisship.com
> -----Original Message-----
> From: Drew McAuliffe [mailto:drew@lowerunit.com]
> Sent: Wednesday, April 14, 2004 9:23 PM
> To: tapestry-user@jakarta.apache.org
> Subject: Dynamic component binding
>
>
> I'm just starting to delve into Tapestry, so if there's something I've
> missed so far in answer to this question, I apologize in advance.
>
> Here's my question: Is it possible, when Tapestry is loaded,
> to have some
> mechanism of dynamically loading components in such a way
> that they can
> decorate other components? What I'm basically looking to do
> is something
> similar to the way eclipse plugins work, but in the web world. In the
> eclipse runtime, a plugin declares extension points. Another
> plugin declares
> that it is extending those extension points. I'm trying to
> see if there's a
> way to do the same thing in a web application, and thus far,
> Tapestry seems
> to offer the most promise.
>
> As an example, imagine "SomePageA" is a component declares an
> extension
> point called "tabs". Another component, "ExtensionB", wants
> to extend that
> page, specifically by adding a new tab to the "tabs"
> extension point. In
> practice, this would mean that a user would see a new tab on the page.
>
> The problem with most web applications, or other kinds of
> apps that don't
> use a dynamic plugin discovery runtime like eclipse, is that
> to get that new
> tab in the original page, you have to couple the components
> "SomePageA" and
> "ExtensionB" together, explicitly wiring them. Tapestry seems
> to work the
> same, so you would have to modify the page specification in
> "SomePageA" to
> add the new tab.
>
> What I would like to do is to limit the dependency so that
> the "SomePageA"
> component can be packaged and deployed completely separately from
> "ExtensionB" and wouldn't need to be modified if "ExtensionB"
> were used.
> Something would have to load up "ExtensionB", see that it has
> an extension
> for the "tabs" extension point on "SomePageA", and
> dynamically bind it into
> the "SomePageA" component, displaying as a new tabbed page.
> Again, the key
> is that both components can be packaged completely separately, and
> "SomePageA" doesn't have to know anything at all about any extensions.
>
> Does this sound possible? Is this something that someone else
> has played
> around with? I think this could be an incredibly useful
> feature. I'm hoping
> that Tapestry's component-based nature would make this more
> possible than it
> would be with other frameworks. If it is, you could feasibly
> create a set of
> web-specific plugins, and arrange them as necessary to build
> applications,
> just like you see happening in Eclipse (where the workbench
> gets extended to
> provide all kinds of useful functionality-- like Spindle!).
>
> Thanks,
>
> Drew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Dynamic component binding
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
Quick man, get the to http://jakarta.apache.org/hivemind/
HiveMind is going to provide a new infrastructure for Tapestry 3.1. I think of it as kind of
information soup, that should allow some or all of the things you're discussing to be implemented.
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Tapestry: Java Web Components
Creator, HiveMind
http://howardlewisship.com
> -----Original Message-----
> From: Drew McAuliffe [mailto:drew@lowerunit.com]
> Sent: Wednesday, April 14, 2004 9:23 PM
> To: tapestry-user@jakarta.apache.org
> Subject: Dynamic component binding
>
>
> I'm just starting to delve into Tapestry, so if there's something I've
> missed so far in answer to this question, I apologize in advance.
>
> Here's my question: Is it possible, when Tapestry is loaded,
> to have some
> mechanism of dynamically loading components in such a way
> that they can
> decorate other components? What I'm basically looking to do
> is something
> similar to the way eclipse plugins work, but in the web world. In the
> eclipse runtime, a plugin declares extension points. Another
> plugin declares
> that it is extending those extension points. I'm trying to
> see if there's a
> way to do the same thing in a web application, and thus far,
> Tapestry seems
> to offer the most promise.
>
> As an example, imagine "SomePageA" is a component declares an
> extension
> point called "tabs". Another component, "ExtensionB", wants
> to extend that
> page, specifically by adding a new tab to the "tabs"
> extension point. In
> practice, this would mean that a user would see a new tab on the page.
>
> The problem with most web applications, or other kinds of
> apps that don't
> use a dynamic plugin discovery runtime like eclipse, is that
> to get that new
> tab in the original page, you have to couple the components
> "SomePageA" and
> "ExtensionB" together, explicitly wiring them. Tapestry seems
> to work the
> same, so you would have to modify the page specification in
> "SomePageA" to
> add the new tab.
>
> What I would like to do is to limit the dependency so that
> the "SomePageA"
> component can be packaged and deployed completely separately from
> "ExtensionB" and wouldn't need to be modified if "ExtensionB"
> were used.
> Something would have to load up "ExtensionB", see that it has
> an extension
> for the "tabs" extension point on "SomePageA", and
> dynamically bind it into
> the "SomePageA" component, displaying as a new tabbed page.
> Again, the key
> is that both components can be packaged completely separately, and
> "SomePageA" doesn't have to know anything at all about any extensions.
>
> Does this sound possible? Is this something that someone else
> has played
> around with? I think this could be an incredibly useful
> feature. I'm hoping
> that Tapestry's component-based nature would make this more
> possible than it
> would be with other frameworks. If it is, you could feasibly
> create a set of
> web-specific plugins, and arrange them as necessary to build
> applications,
> just like you see happening in Eclipse (where the workbench
> gets extended to
> provide all kinds of useful functionality-- like Spindle!).
>
> Thanks,
>
> Drew
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org