We recently had a few browser specific issues,
http://issues.apache.org/jira/browse/TAPESTRY-1141 (already fixed)
http://issues.apache.org/jira/browse/TAPESTRY-1129 (same as an old tacos
bug, i.e. fix is already known)
Now, i wouldn't like closing them without some sort of browser specific
testing
[
http://issues.apache.org/jira/browse/TAPESTRY-1141?page=comments#action_12448015
]
Andreas Andreou commented on TAPESTRY-1141:
---
Fixed... in the case described, FF considers the textfield to be the target of
the generated event (inst
My only objection to putting the version number in the is that
becomes one more thing to maintain when the release number changes.
On 11/7/06, andyhot <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship wrote:
> Sounds fine to me. I think Tapestry 5 is already on the right track:
>
>Tapestry Cor
Martin Strand wrote:
> Ask the mevenide dudes to add version number to the name displayed in
> netbeans
My initial reaction as well... on the other hand, i'm more used to thinking
"Tapestry 4" as a separate product being in version 1.1 :)
>
> On Wed, 08 Nov 2006 00:15:43 +0100, andyhot <[EMAIL PROT
Ask the mevenide dudes to add version number to the name displayed in
netbeans
On Wed, 08 Nov 2006 00:15:43 +0100, andyhot <[EMAIL PROTECTED]> wrote:
Howard Lewis Ship wrote:
Sounds fine to me. I think Tapestry 5 is already on the right track:
Tapestry Core Library
doh... i did the c
Howard Lewis Ship wrote:
> Sounds fine to me. I think Tapestry 5 is already on the right track:
>
>Tapestry Core Library
doh... i did the change in the 4.1 pom, but now i can't easily tell if i
have
4.1 or 5 open... they're both named "Tapestry Core Library" :(
Is "Tapestry 4.1 Core Library
[ http://issues.apache.org/jira/browse/TAPESTRY-1141?page=all ]
Andreas Andreou reassigned TAPESTRY-1141:
-
Assignee: Andreas Andreou
> Async form fails if keyboard is used to trigger the submit...
> ---
[
http://issues.apache.org/jira/browse/TAPESTRY-1141?page=comments#action_12447909
]
Andreas Andreou commented on TAPESTRY-1141:
---
IE 6, Konqueror, Opera all work... so this looks to be FF specific.
At first i thought this to relate to
Sounds fine to me. I think Tapestry 5 is already on the right track:
Tapestry Core Library
On 11/7/06, andyhot <[EMAIL PROTECTED]> wrote:
Anyone minds making the (project) names in all pom.xml
a bit more descriptive?
i.e.
'Tapestry Core Library' instead of 'Core Library'
Mevenide uses tha
I was talking about making the change in 4.1 since that's where all the
newer development is going, but I'm still on the 4.0 series. I made a quick
test app using 4.1 and it does indeed work as you've described. Thanks for
clearing that up for me, and sorry for the confusion!
On 11/7/06, andyhot
In maven1, in such cases one could simply use
as described in
http://maven.apache.org/maven-1.x/plugins/xdoc/reference/xdocs.html
Too bad this doesn't seem to work in maven2 + even the generated html is
invalid
>
> +
>
>
--
Andreas Andreou - [EMAIL PROTECTED] - http:
I'm thinking no..., but want to make sure.
Is Tapestry 4.1 supported on JDK/JRE 1.4?
--
Cumquat Information Technology
De Dreef 19
3706 BR Zeist
T +31 (0)30 - 6940490
F +31 (0)30 - 6940499
http://www.cumquat.nl
[EMAIL PROTECTED]
M +31 6 51 169 556
--- Begin Message ---
Tapestry support and dev
D&J Gredler wrote:
> I've tried it in version 4.0.2 and it exhibits the behavior I
> described... I
> guess this is one of the things that have changed in 4.1?
Yea, thought you were talking about 4.1, weren't you?
The jwcid is still used but if the user specifies an id parameter,
it acts like an
I've tried it in version 4.0.2 and it exhibits the behavior I described... I
guess this is one of the things that have changed in 4.1?
On 11/7/06, andyhot <[EMAIL PROTECTED]> wrote:
D&J Gredler wrote:
> Unless I've overlooked something, I believe in this context "id" means
> the
> jwcid, not th
D&J Gredler wrote:
> Unless I've overlooked something, I believe in this context "id" means
> the
> jwcid, not the id binding. I'm reusing components in a loop, so I
> can't just
> modify the jwcid each time through the loop.
> So for your example below, the name would still be foo / foo_0 / foo_1
Anyone minds making the (project) names in all pom.xml
a bit more descriptive?
i.e.
'Tapestry Core Library' instead of 'Core Library'
Mevenide uses that value to name the projects within the IDE...
And anyway, i don't mind adding tapestry everywhere.
--
Andreas Andreou - [EMAIL PROTECTED] - http
Unless I've overlooked something, I believe in this context "id" means the
jwcid, not the id binding. I'm reusing components in a loop, so I can't just
modify the jwcid each time through the loop.
So for your example below, the name would still be foo / foo_0 / foo_1 /
etc.
On 11/7/06, andyhot <
Why don't you set the id then... the name (as you found out) is derived
from it...
So use:
D&J Gredler wrote:
> Hi Robert,
>
> In Tap4 you get foo, foo_0, foo_1, etc, but the idea is the same. What
> I'm
> suggesting is allowing the user to change the "foo" part, but still going
> through the IdA
Hi Robert,
In Tap4 you get foo, foo_0, foo_1, etc, but the idea is the same. What I'm
suggesting is allowing the user to change the "foo" part, but still going
through the IdAllocator steps that ensure unique naming. Most likely this
would involve removing
reserved-parameter name="name"
"Name" is a reserved parameter because all form components output their
own name. Tapestry handles the work of making sure each form component
outputs a unique name. The name will be based on the id of the component.
would render text fields along the lines of (in tap3, at least):
And so f
Hmm... no one seems to know.
Jesse & Andy, how would you feel about a patch to 4.1 that makes "name" an
assignable parameter on all form components?
On 10/25/06, D&J Gredler <[EMAIL PROTECTED]> wrote:
Hi,
I'm wondering if someone can give me a quick explanation for why "name" is
a reserved p
21 matches
Mail list logo
