The subtle difference is that prop:url is potentially a read/write
binding (the component could attempt to change its parameter which
would attempt to update the url property, if a settter method exists).
Expansions always result in a read-only value.
You can also do things like:
mailto:${cont
I'm looking at the Testify framework, and while it looks promising, it still
doesn't connect up the spring layer.
It also puts a /foo in front of every asset and page link on my page.
Frustrating
--
View this message in context:
http://old.nabble.com/Unit-testing-with-tapestry-5.1-and-spr
On Mon, 05 Apr 2010 18:19:21 -0300, Pierce T. Wetter III
wrote:
Are these exactly the same or is there a subtle distinction between
them?>
This is the same as ${prop:url}. The prop binding is the default one for
expressions and for the majority of components' parameters.
>> This is a side-effect of Tapestry's static structure approach. A
>> component X embedded in the template of component Y is instantiated as
>> an object attached to object Y. This instantiation happens once, at
>> page load time.
>>
>> For X to be recursive (to contain an X), we would need to in
Are these exactly the same or is there a subtle distinction between them?
Pierce
I mean, leaky abstractions.
On Mon, Apr 5, 2010 at 2:18 PM, Howard Lewis Ship wrote:
> This is a side-effect of Tapestry's static structure approach. A
> component X embedded in the template of component Y is instantiated as
> an object attached to object Y. This instantiation happens once, at
>
This is a side-effect of Tapestry's static structure approach. A
component X embedded in the template of component Y is instantiated as
an object attached to object Y. This instantiation happens once, at
page load time.
For X to be recursive (to contain an X), we would need to instantiate
X and as
On Mon, 05 Apr 2010 18:07:46 -0300, Pierce T. Wetter III
wrote:
Just out of curiosity, why no recursive components? I re-implemented
my navigation menu using a solution I found on Google, but it would have
been a lot simpler if the menu items had been recursive instead having
to use d
Just out of curiosity, why no recursive components? I re-implemented my
navigation menu using a solution I found on Google, but it would have been a
lot simpler if the menu items had been recursive instead having to use delegate
stuff that felt very much like voodoo...
Pierce
Unless the dependency specifies a version range that your lib is
outside of. But as Kalle said - start with supplying your own
dependency with desired version which should satisfy your libs'
requirements. If it does not then it's time to exclude. But be aware
that you will be overriding author's de
No need to exclude anything. The nearest resolution wins; if you
specify a different version for the same library in your pom, that's
version you are going to get.
Kalle
On Mon, Apr 5, 2010 at 11:40 AM, Thiago H. de Paula Figueiredo
wrote:
> On Mon, 05 Apr 2010 15:18:18 -0300, Everton Agner
>
Thank you!! It was kinda a Maven problem. :)
But, I also want to know if anyone has done that and haven't got any bug or
something after the upgrade.
Thanks!
- Everton
De: Thiago H. de Paula Figueiredo
Para: Tapestry users
Enviadas: Segunda-feira, 5 de Abr
Hi,
As I've said before, I'm integration Envers in my T5.1 Application, and
everything seems clear except for : How can I obtain the Request object by the
IoC if the Enver's RevisionListener class is not controlled by the IoC? (it's a
Singleton per EntityManagerFactory object as far as I've rea
On Mon, 05 Apr 2010 15:18:18 -0300, Everton Agner
wrote:
Well, has anyone upgraded the [tapestry-hibernate-5.1.0.5.jar] lib to a
newer Hibernate version via Maven?
Use the exclusion tag and provide you own Hibernate dependency. It's
documented here:
http://maven.apache.org/guides/intro
I will start to integrate the Envers JBoss Auditing framework in a T5.1 App,
and I've found out that there was a recent Hibernate 3.5-Final release at Apr 1
(April's fool joke? lol) with Envers already integrated.
Well, has anyone upgraded the [tapestry-hibernate-5.1.0.5.jar] lib to a newer
Hib
I'm surprised at the lack of information about how to get the page tester
wired up correctly in tapestry 5.1 to use spring beans. It looks like the
API for the the SpringModuleDef changed between 5.0 and 5.1 for connecting
the page tester to the spring context.
Testing a Tapestry application out
I want to create a module which consists of several parts:
- a JS which overrides tapestry's client side validation
- a collection of css files forming a CSS Framework
Now I am facing a problem:
1. How to make all the css assets available through the module?
2. How to automatically include the JS
17 matches
Mail list logo
