Re: dynamic component injection

[Martino Piccinato <ma...@gmail.com>]

did you find any cleaner way to do this?

I think this problem is not just related to "one page applications" but
apply also to any page/component that depending un user actions must show
different enough content (unless one wants to go with EventListener and a
long  ugly list of IF components...)

Re: dynamic component injection

[Martino Piccinato <ma...@gmail.com>]

tnx a lot Alejandro!

this is exactly what I was looking for, block/renderblock components
combined with EventListener  can be really powerful stuff but I didn't
realize it until I read your example.

It's also very interesting the way you use that Editors page as a "block
component repository" and the ComponentAddress beans.

Re: dynamic component injection

[Alejandro Scandroli <al...@gmail.com>]

Hi Guys,

I don't know if this is what are you looking for but here is how we
handle our "dynamic" components at Trails.

First we have a page which contains what we call "editors" (our
"dynamic" components):
http://svn.codehaus.org/trails/trunk/trails/modules/trails-core/src/main/resources/org/trails/page/Editors.html
http://svn.codehaus.org/trails/trunk/trails/modules/trails-core/src/main/resources/org/trails/page/Editors.page
They are all wrapped by @Blocks.

Then we have a map where the key is an ongl expression we use to
evaluate if that is right component for render a property, and  the
value is a ComponentAddress. The map definition is in our sping
configuration file.
Here is an example of one entry:
<entry>
	<key>
		<value>string and !large and !identifier</value>
	</key>
	<bean class="org.apache.tapestry.util.ComponentAddress">
		<constructor-arg index="0">
			<value>trails:Editors</value> <!-- it refers to Editors page -->
		</constructor-arg>
		<constructor-arg index="1">
			<value>stringEditor</value>
		</constructor-arg>
	</bean>
</entry>

So "stringEditor" is the name of the block we are going to look for in
our Editors page.

Then wherever we need to render one of those blocks we do:

<span jwcid="$content$">	
    <span jwcid="renderBlock@Block" block="ognl:block"/>
</span>

and

public Block getBlock()
{
	ComponentAddress componentAddress = get the ComponentAddress from the map.
componentAddress.findComponent(getPage().getRequestCycle()); //activate it.
// set all the properties you need to set

	return (Block) componentAddress;
}

That's all!
This is safe to use inside a For or Table or wherever you need to use it.

Of course an ognl expressions map is not a good fit for everyone, so
you can use whatever service you need to implement your logic as long
as it returns a ComponentAddress from the Editors page.

I hope this helps you.
Saluti.
Alejandro.


On 6/20/07, Martino Piccinato <ma...@gmail.com> wrote:
> did you find any cleaner way to do this?
>
> I think this problem is not just related to "one page applications" but
> apply also to any page/component that depending un user actions must show
> different enough content (unless one wants to go with EventListener and a
> long  ugly list of IF components...)
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org