date:20060802

Oh what a familiar theme we weave

I wasn't very happy with the way we had to do certain things in tacos the
first time around, so I'm trying as much as possible to not let myself
"apply tacos" to Tapestry as much as possible.

That being said, I have added a few key services which tacos could very
easily use to replace the core functionality aspects of things.

Generally speaking I tried to make the tacos components act/look as much
like their Tapestry counterparts to help ease the learning curve when going
from Tapestry - > Tacos, so I think the same will be true when going from
Tacos -> Tapestry.

AjaxEventSubmit is a very powerful/nice component, but I've always
considered it an "abomination" in terms of design. I'm much happier with
@EventListener.

I'm still not sure I like the idea of the standard parameter set
"updateComponents/effects/etc" but we'll see. Maybe there really isn't going
to be a clear and victorious winner for these things.

Like I said in a previous posting though, I've only laid down the internal
support necessary to do these things so far. ..Now is more the time for
component developers/users of tacos to start thinking about how they've been
doing things so far and what might make things feel/seem more intuitive.

I think EventListener is really the only "official" new thing that I'm happy
with the design of. (leaving out effects/what to update/etc on purpose)

Either way the end result can't be too radical(for T4 at least ;) ). It
should hopefully be based on existing concepts/tasks that every day Tapestry
users go through with simple extensions of those concepts where it makes
sense. (and with minimal effort/typing..I hate typing)

On 8/2/06, Karthik N <[EMAIL PROTECTED]> wrote:

I'm also very keen to know the answer to this.

Considering that Tap 4.1 is "round-the-corner", we're wondering whether to
go ahead and use Tacos in our projects, and be able to refactor then with
minimal effort when they become a part of Tapestry 4.1?  Also any Tacos
components that might get deprecated?

Essentially we want to make our applications 4.1 friendly ...

Any pointers/answers would be of most help!  Thanks!!

On 8/2/06, Murthy Parthasarathi <[EMAIL PROTECTED]> wrote:
>
> Hi All.
>
> If I have a Tapestry 4.0 application, that uses Tacos, what will
> be
> the effort involved in moving this app to Tapestry 4.1? Are Tacos
> components going to be available as-is, or will there be a lot of
> changes needed to the existing components?
>
> i.e. Should we limit ourselves from not using Tacos in 4.1?
>
> Cheers
> Murthy
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Thanks, Karthik

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: Tap 4.0 + Tacos --> Upgrade to Tap 4.1

2006-08-02 Thread Karthik N


I'm also very keen to know the answer to this.

Considering that Tap 4.1 is "round-the-corner", we're wondering whether to
go ahead and use Tacos in our projects, and be able to refactor then with
minimal effort when they become a part of Tapestry 4.1?  Also any Tacos
components that might get deprecated?

Essentially we want to make our applications 4.1 friendly ...

Any pointers/answers would be of most help!  Thanks!!

On 8/2/06, Murthy Parthasarathi <[EMAIL PROTECTED]> wrote:


Hi All.

If I have a Tapestry 4.0 application, that uses Tacos, what will
be
the effort involved in moving this app to Tapestry 4.1? Are Tacos
components going to be available as-is, or will there be a lot of
changes needed to the existing components?

i.e. Should we limit ourselves from not using Tacos in 4.1?

Cheers
Murthy


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Thanks, Karthik

Re: Auto-updating a drop-down list


Hi Waimun.

DynamicSelectionList works fine, but I needed to change it a bit for my use.

Just download it and see if it does what you want. Shing Hing Man (who is on
this list) wrote it, and has docs and online demos here:
http://lombok.demon.co.uk/tapestryDemo/welcome?service=page/DynamicSelectionList

If you need to change it, email him (or me) about it. ;-)

Cheers,
Nick.


Waimun Yeow wrote:

Jesse and Nick,

Thanks for the suggestions (1) EventListener (2) DynamicSelectionList.

I am currently using Tap 3.03 and perhaps this is a good chance to  
upgrade if I want to take advantage of 4.1 features. But I am  concerned 
whether if I need to make a lot of changes to the way I  configured the 
application to integrate Spring with Tapestry in  section 15.4.2.3 at  
(http://www.springframework.org/docs/reference/ webintegration.html).


The DynamicSelectionList is also a good option since you said it  works 
with T3 (with tweaks). Perhaps you can point me to an example  and also 
provide the tweaks in order for it to work.



Thanks,
waimun


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Q: tapestry-spring

2006-08-02 Thread Anton Nikitin

Hi all,

On his tapestry-spring contribution
[http://howardlewisship.com/tapestry-javaforge/tapestry-spring/], Howard
mentioned that "...injecting Spring beans that are not singletons doesn't
work properly..."

How exactly is this manifested?

I tried a very quick example, using a bean mapped like so:


Source:
public class NonSingletonBean {
private Date date;

public NonSingletonBean() {
this.date = new Date(); 
}
public String currentDate() {
return date.toString();
}
}

In Home.java:
[...]
@InjectObject("spring:myHello")
public abstract NonSingletonBean getHello();
[...]
public IPage onSubmit() {
System.out.println(getHello().currentDate());
}

The injected bean would behave as expected - i.e. when bean configured as
singleton="false", the onSubmit handler would produce a new date string on
every call; when using bean default (singleton), the date was fixed to
whenever value when it was first created.

What lifecycle model is compromised when injecting beans this way? Is it
still a problem if I inject application context through a
ApplicationContextAware bean, and then call ac.getBean("someBean") in my
page class?


Many thanks,
- Anton


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlets on Tapestry 4.1

You don't need the @Script processing things to include scripts. (Esp with
the AjaxShellDelegate I pointed out.)

The default configuration for using this delegate is currently encapsulated
in
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/java/org/apache/tapestry/html/Shell.jwc?view=markup

The gist of it is that it's a simple IAsset resource.

If this is going to cross boundaries into the portlet world I should
probably go a bit farther by doing a composition of components, possibly
providing a small generic @IncludeScript sort of component that will allow
IAsset style context path statements. (Since you will already have
dojo/tapestry in your classpath this would be the preferred method).

I probably need to think about this some more to be sure I don't screw it
up.

As far as including/not including scripts in the head, I think it will work
fine in either scenerio. (Not sure if caching is handled the same in either
though?)

Either way it's not very hard to include js packages in the document head
(portlet specs be damned! no just kidding of course...), take a look at the
tapestry.loadScriptFromUrl function here:

http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/js/tapestry/core.js?view=markup

A combination of setting the assets up like Shell.jwc does in the first url
I gave you + using AjaxShellDelegate should temporarily solve your problem
until a more permanent solution is found/designed. (I would probably create
a very simple component to wrap the ShellDelegate, sort of like @Shell, only
you won't need to output any actual html content. )

On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]>

Still, for those odd cases where we control the entire page, how can I
link in the .js and other stuff.  I don't mind, for example, having it part
of all our portal pages.  I.e., is there a way to statically link to the
relevant .js files as-is that would work, or must parts be processed by the
Script-processing tools provided by Tapestry?

Thanks,

Ezra Epstein

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 6:24 PM
To: Tapestry users
Subject: Re: Portlets on Tapestry 4.1

Ok, I think I'm a little out of my element here.

I can't honestly say I understand the day to day sort of development
patterns that people use with Tapestry portlets.

Is there an equivalent idea to something containing each page? (ie
something that handles stylesheets/ etc  ?)

Rather than trying to pull what I think is the right way out of my arse,
can the community help me out a little here? ;)

I do have one specific IRender "bean" sort of class that the @Shell
component delegates the work of rendering the tapestry/dojo/browser debug
configuration includes to. It can be found here:

http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html
.

If the functionality this provides sounds somewhat palatable I can try
refactoring the naming a little bit to eliminate the verbage of "Shell".
(I'd like to remove AJAX as well...)

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmm...Good question. I will answer with a documentation page.
>
>
> On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
> >
> > We want to move to 4.1 for our portlets.  Reading up I find:
> >
> > "By default, the Shell component will include the core dojo
> > javascript object dojo.js, as well as the new core Tapestry
> > javascript object - core.js. This means that you don't have to worry
> > about how to include dojo or Tapestry javascript on any of your
> > pages, they will already be available."
> >
> > Of course, that's not the case for portlets.
> >
> > Is there a simple step-by-step how-to for those of us who don't
> > (can't) use the Shell component.
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

RE: Portlets on Tapestry 4.1

2006-08-02 Thread Epstein, Ezra

I need to go double-check the portlet spec, but my current understanding is 
that the portlet spec does not provide any way for portlets to contribute to 
the head content of a page!  (Does this sound like a common occurrence in JCP 
"standards"?)

The Appendix E of the spec http://www.jcp.org/en/jsr/detail?id=168 is relevant 
here:

Features Deferred to Future Releases

The following are some of the features that would be considered in future 
versions of the
Portlet Specification. The technical details of these features would be 
resolved by the
5 Expert Group of the corresponding JSR.
* Portlet filters
* Inter-portlet, event style, communication
* Allow portlets to produce and influence markup outside of the portlet fragment

Notice the very last one there.  That kinda sums it up.  (Some would say that, 
as a result, Portlet's a la this spec, suck.)

Here are other relevant parts of the spec:

Portlets do not have access to the following functionality provided by servlets:
* Setting the character set encoding of the response
* Setting HTTP headers on the response
* The URL of the client request to the portal

Portlets generating HTML fragments must not use the following tags: base, body,
iframe, frame, frameset, head, html and title.

Portlets generating XHTML and XHTML-Basic fragments must not use the following
tags: base, body, iframe, head, html and title.

Within their content, portlets may include elements that must be unique within 
the whole
portal page. JavaScript functions and variables are an example of this 

The getNamespace method must provide the portlet with a mechanism that ensures 
the
uniqueness of the returned string in the whole portal page.  For example, the
getNamespace method would return a unique string that could be prefixed to a
JavaScript variable name within the content generated by the portlet, ensuring 
its
uniqueness in the whole page. The getNamespace method must return the same 
value if
invoked multiple times within a render request.

Still, for those odd cases where we control the entire page, how can I link in 
the .js and other stuff.  I don't mind, for example, having it part of all our 
portal pages.  I.e., is there a way to statically link to the relevant .js 
files as-is that would work, or must parts be processed by the 
Script-processing tools provided by Tapestry?

Thanks, 

Ezra Epstein 

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 02, 2006 6:24 PM
To: Tapestry users
Subject: Re: Portlets on Tapestry 4.1

Ok, I think I'm a little out of my element here.

I can't honestly say I understand the day to day sort of development patterns 
that people use with Tapestry portlets.

Is there an equivalent idea to something containing each page? (ie something 
that handles stylesheets/ etc  ?)

Rather than trying to pull what I think is the right way out of my arse, can 
the community help me out a little here? ;)

I do have one specific IRender "bean" sort of class that the @Shell component 
delegates the work of rendering the tapestry/dojo/browser debug configuration 
includes to. It can be found here:
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html
.

If the functionality this provides sounds somewhat palatable I can try 
refactoring the naming a little bit to eliminate the verbage of "Shell".
(I'd like to remove AJAX as well...)

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmm...Good question. I will answer with a documentation page.
>
>
> On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
> >
> > We want to move to 4.1 for our portlets.  Reading up I find:
> >
> > "By default, the Shell component will include the core dojo 
> > javascript object dojo.js, as well as the new core Tapestry 
> > javascript object - core.js. This means that you don't have to worry 
> > about how to include dojo or Tapestry javascript on any of your 
> > pages, they will already be available."
> >
> > Of course, that's not the case for portlets.
> >
> > Is there a simple step-by-step how-to for those of us who don't 
> > (can't) use the Shell component.
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> > 
> > - To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around 
> dojo/tapestry/tacos/hivemind.
>

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around dojo/tapestry/tacos/hivemind.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlets on Tapestry 4.1

More importantly than that, we'd have a potential "situation" wrt ~other~
portlets also including javascript.

It seems like something that you'd think would come up more often. I'd be
interested in knowing if things like css/script includes have been addressed
by anyone else in the portlet community?

For example, the current delegate might optionally have to include a
Compatibility checking sort of script to ensure that no other dojo or
tapestry script librariers were already being included in the browser. If
they were included we might then have to check versions and do "something"
if they are found to be incompatible. (both dojo and tapestry include
release version meta information in the js runtime, so we can write logic to
check it fairly easily.)

Thoughts ?

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Ok, I think I'm a little out of my element here.

I can't honestly say I understand the day to day sort of development
patterns that people use with Tapestry portlets.

Is there an equivalent idea to something containing each page? (ie
something that handles stylesheets/ etc  ?)

Rather than trying to pull what I think is the right way out of my arse,
can the community help me out a little here? ;)

I do have one specific IRender "bean" sort of class that the @Shell
component delegates the work of rendering the tapestry/dojo/browser debug
configuration includes to. It can be found here: 
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html
.

If the functionality this provides sounds somewhat palatable I can try
refactoring the naming a little bit to eliminate the verbage of "Shell".
(I'd like to remove AJAX as well...)

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmm...Good question. I will answer with a documentation page.
>
>
> On 8/2/06, Epstein, Ezra < [EMAIL PROTECTED]> wrote:
> >
> > We want to move to 4.1 for our portlets.  Reading up I find:
> >
> > "By default, the Shell component will include the core dojo javascript
> > object dojo.js, as well as the new core Tapestry javascript object -
> > core.js. This means that you don't have to worry about how to include
> > dojo or Tapestry javascript on any of your pages, they will already be
> > available."
> >
> > Of course, that's not the case for portlets.
> >
> > Is there a simple step-by-step how-to for those of us who don't
> > (can't) use the Shell component.
> >
> > Thanks,
> >
> > Ezra Epstein
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: Did IRequestCycle.getResponseBuilder() disappear in the latest snapshot? if so, whats the replacement?


No. (Geez I hope not)

What gave you that impression?

On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:


Hello all,

Did IRequestCycle.getResponseBuilder() disappear in the latest
snapshot? if so, whats the replacement?

Thanks,

Joshua

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Did IRequestCycle.getResponseBuilder() disappear in the latest snapshot? if so, whats the replacement?

2006-08-02 Thread Josh Long


Hello all,

Did IRequestCycle.getResponseBuilder() disappear in the latest
snapshot? if so, whats the replacement?

Thanks,

Joshua

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlets on Tapestry 4.1

Ok, I think I'm a little out of my element here.

I can't honestly say I understand the day to day sort of development
patterns that people use with Tapestry portlets.

Is there an equivalent idea to something containing each page? (ie something
that handles stylesheets/ etc  ?)

Rather than trying to pull what I think is the right way out of my arse, can
the community help me out a little here? ;)

I do have one specific IRender "bean" sort of class that the @Shell
component delegates the work of rendering the tapestry/dojo/browser debug
configuration includes to. It can be found here:
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/dojo/AjaxShellDelegate.html
.

If the functionality this provides sounds somewhat palatable I can try
refactoring the naming a little bit to eliminate the verbage of "Shell".
(I'd like to remove AJAX as well...)

On 8/2/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:

Hmm...Good question. I will answer with a documentation page.

On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:
>
> We want to move to 4.1 for our portlets.  Reading up I find:
>
> "By default, the Shell component will include the core dojo javascript
> object dojo.js, as well as the new core Tapestry javascript object -
> core.js. This means that you don't have to worry about how to include
> dojo or Tapestry javascript on any of your pages, they will already be
> available."
>
> Of course, that's not the case for portlets.
>
> Is there a simple step-by-step how-to for those of us who don't (can't)
> use the Shell component.
>
> Thanks,
>
> Ezra Epstein
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

RE: recursive rendering

2006-08-02 Thread Epstein, Ezra

This may not be the issue, but...

You could make a "dyna-eval" component that (re-)evaluates an ognl expression 
wherever/whenever you choose.

OGNL is pretty easy to work with.

Perhaps that could work? 

Thanks, 

Ezra Epstein 

-Original Message-
From: Dan Adams [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 02, 2006 2:31 PM
To: Tapestry users
Subject: Re: recursive rendering

Thanks Mike. Yeah, I've read that article at least twice now and read through 
the code. :) I'm having a problem that you may have run into; much like your 
code the block to render is returned via an ognl expression and it apprears the 
the expression is only being evaluated once and not each time. Did you ever 
have this problem?

On Tue, 2006-08-01 at 16:04 -0700, Mike Henderson wrote:
> Hi,
>   It's a T3 example but it should show how it's done:
> 
> http://www.behindthesite.com/blog/C1931765677/E923478269/index.html
> 
> Mike
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
--
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Portlets on Tapestry 4.1


Hmm...Good question. I will answer with a documentation page.

On 8/2/06, Epstein, Ezra <[EMAIL PROTECTED]> wrote:


We want to move to 4.1 for our portlets.  Reading up I find:

"By default, the Shell component will include the core dojo javascript
object dojo.js, as well as the new core Tapestry javascript object -
core.js. This means that you don't have to worry about how to include dojo
or Tapestry javascript on any of your pages, they will already be
available."

Of course, that's not the case for portlets.

Is there a simple step-by-step how-to for those of us who don't (can't)
use the Shell component.

Thanks,

Ezra Epstein

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Portlets on Tapestry 4.1

2006-08-02 Thread Epstein, Ezra

We want to move to 4.1 for our portlets.  Reading up I find:

"By default, the Shell component will include the core dojo javascript object 
dojo.js, as well as the new core Tapestry javascript object - core.js. This 
means that you don't have to worry about how to include dojo or Tapestry 
javascript on any of your pages, they will already be available."

Of course, that's not the case for portlets.  

Is there a simple step-by-step how-to for those of us who don't (can't) use the 
Shell component. 

Thanks, 

Ezra Epstein 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ajax form question about Tapestry 4.1

Sounds like a possible bug. It makes sense though now..

All the @EventListener would do in this instance is bind to the event
happening, not interfere with "what" happens. Your form submitting probably
just blew away any chance of having the ajax stuff completing :)

On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:

> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a
good
> way to do this without code duplication.

I'm all for reducing the number of parameters as long as there some other
way to do the same thing. It's just that I couldn't get it to work in any
other way.
But I also think the updateComponents parameter could be very useful. In
some cases it could be a welcome replacement to writing a listener method
with an EventListener annotation.

> As for Forms, you could very easily use @EventListener, targeting a form
+
> event of "onsubmit" to get the same result. (Use ResponseBuilder to
update
> whatever components you want, possibly event the whole form so you see
the
> server side rendered validators.)

Yes, I tried exactly that:

@EventListener(targets="form", events="onsubmit")
public void myListener(IRequestCycle cycle) {
   ... do something ...
   cycle.getResponseBuilder().updateComponent("x");
}

But when I click on a submit button, the entire page is still reloaded. I
tried it with my submit button's action/listener parameter being the same
listener as the EventListener annotation.
From what I could understand from the tests I made, the component "x" (as
in
the above example) gets rendered twice, once for the ajax update and once
more for the page reload.
I think I'm failing somehow to tell the framework that this should be an
ajax-only request. Since you said it should work, it could be something
that
I'm doing wrong, or could be a bug that shows under certain conditions.
Any ideas?

Cheers
Denis Souza

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED]
Sent: quarta-feira, 2 de agosto de 2006 18:24
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1

I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.

It's probably fair that I at least add them to form/form button based
components though.

As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)

Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.

Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?

If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html -
and
handle the UI part anyway you like.

If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry
client
side decorating logic (not validation logic, you have to override a
different function for that):

tapestry.form.validation.handleMissingField=function(field, profile) {
   /// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or
font
element and give it red **'s if you like
}

Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them
(design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.

On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
>
> Yeah I was sort of wondering the same thing, and in particular, how do
> I get validation messages to render via ajax -- that is, i wat the
> form to go through the normal validation routine and I dont want to
> enable client side validation. I actually kind of like the red stars
> and custom decorators the validation classes afford you...
>
> i remember in tacos there was an example of employing the validators
> (ie, led red asterisks appeared via ajax), is this possible in
> tapestry 4.1 without some weird kludge?
>
> I read in the docs that the default is to disable validation when
> using submitForm -- since most of the use cases would make incurring
> the validation lifecycle cumbersome to the user. Thats the default,
> which implies it can be toggled... can it, and if so, how? ;-)
>
> Thanks,
>
> Josh
>
> On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> > Hi, I was looking at the new Tapestry 4.1 ajax

RE: Ajax form question about Tapestry 4.1

2006-08-02 Thread Denis Souza

> I've been trying to avoid adding too many new parameters (like
> updateComponents) all over the place before I felt like I had found a good
> way to do this without code duplication.

I'm all for reducing the number of parameters as long as there some other
way to do the same thing. It's just that I couldn't get it to work in any
other way.
But I also think the updateComponents parameter could be very useful. In
some cases it could be a welcome replacement to writing a listener method
with an EventListener annotation.

> As for Forms, you could very easily use @EventListener, targeting a form +
> event of "onsubmit" to get the same result. (Use ResponseBuilder to update
> whatever components you want, possibly event the whole form so you see the
> server side rendered validators.)

Yes, I tried exactly that:

@EventListener(targets="form", events="onsubmit")
public void myListener(IRequestCycle cycle) {
   ... do something ...
   cycle.getResponseBuilder().updateComponent("x");
}

But when I click on a submit button, the entire page is still reloaded. I
tried it with my submit button's action/listener parameter being the same
listener as the EventListener annotation.
>From what I could understand from the tests I made, the component "x" (as in
the above example) gets rendered twice, once for the ajax update and once
more for the page reload.
I think I'm failing somehow to tell the framework that this should be an
ajax-only request. Since you said it should work, it could be something that
I'm doing wrong, or could be a bug that shows under certain conditions.
Any ideas?

Cheers
Denis Souza

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: quarta-feira, 2 de agosto de 2006 18:24
To: Tapestry users
Subject: Re: Ajax form question about Tapestry 4.1

I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.

It's probably fair that I at least add them to form/form button based
components though.

As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)

Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.

Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?

If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html - and
handle the UI part anyway you like.

If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry client
side decorating logic (not validation logic, you have to override a
different function for that):

tapestry.form.validation.handleMissingField=function(field, profile) {
   /// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or font
element and give it red **'s if you like
}

Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them (design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.

On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:
>
> Yeah I was sort of wondering the same thing, and in particular, how do
> I get validation messages to render via ajax -- that is, i wat the
> form to go through the normal validation routine and I dont want to
> enable client side validation. I actually kind of like the red stars
> and custom decorators the validation classes afford you...
>
> i remember in tacos there was an example of employing the validators
> (ie, led red asterisks appeared via ajax), is this possible in
> tapestry 4.1 without some weird kludge?
>
> I read in the docs that the default is to disable validation when
> using submitForm -- since most of the use cases would make incurring
> the validation lifecycle cumbersome to the user. Thats the default,
> which implies it can be toggled... can it, and if so, how? ;-)
>
> Thanks,
>
> Josh
>
> On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> > Hi, I was looking at the new Tapestry 4.1 ajax features.
> > EventListener/ResponseBuilder are really nice! Besides the new
> annotations I
> > noticed some components (such as DirectLink) already have the Tacos ajax
> > functionality built in which allows you to update a certain part of the
> page
> > ("updateComponents" parameter), however I didn't find the same

Re: upgrading to 4.1 - question about concepts

Those sound like requirements :)

This is good, I hadn't fully attacked/handled widget support yet (hence the
lack of seeing very many), but I'd love to be able to pick your brain about
more specifics of what/how/why you are doing some of the things with your
widgets. (If it's not a public sort of thing you can email me off list).

The format is currently "similar" to tacos, though handled a little
differently.

The client side file that handles the xml-rpc sort of calls is
http://svn.apache.org/viewvc/tapestry/tapestry4/trunk/tapestry-framework/src/js/tapestry/core.js?view=markup.

The element types/id's mostly come from the ResponseBuilder interface,
http://tapestry.apache.org/tapestry4.1/tapestry-framework/apidocs/org/apache/tapestry/services/ResponseBuilder.html
.

I don't know if I can promise anything this extensive being done in one
weekend but the more input I can get the better. (for day to day pondering's
sake )

On 8/2/06, Ron Piterman <[EMAIL PROTECTED]> wrote:

Hi,
In an application I am currently working on (tapestry 4.0) we use
extensivley dojo widgets and a custom ajax render cycle.

Usually the Ajax responses are rendered by a special renderer which
wrapps components renders inside a kind of xml-rpc. This is parsed by
java scripts and performs different actions:

It looks something like:

...
and so on.

The nice thing is, the widget that sends the request handles the
response, so one can call from inside tapestry methods on the widgets,
passing component render-results as parameters.

Now as far as I understand from the docu, tapestry 4.1 contains one very
important method for ajax response: ResponseBuilder.updateComponent(...)

this will end in a replace-by-id, which is quite trivial - but what is
the tap4.1 way of doing other things like openning a dojo dialog,
changing status of existing widgets (and thus the under- or overlying
html) and so on? Do I have to write javascript templates for all of
those actions?

As far as can remember from tacos, the ajax response was also a sort of
xml-rpc, handled by the tacos JS library. I would guess it was
"imported" into tap4.1 - is there an overview of this somewhere? (how
the response should look like ...) - more under the hood as in the
existing docu?

Thanx for reading that long ;)

Cheers,
Ron

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: recursive rendering

Thanks Mike. Yeah, I've read that article at least twice now and read
through the code. :) I'm having a problem that you may have run into;
much like your code the block to render is returned via an ognl
expression and it apprears the the expression is only being evaluated
once and not each time. Did you ever have this problem?

On Tue, 2006-08-01 at 16:04 -0700, Mike Henderson wrote:
> Hi,
>   It's a T3 example but it should show how it's done:
> 
> http://www.behindthesite.com/blog/C1931765677/E923478269/index.html
> 
> Mike
> 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-- 
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: recursive rendering

Thanks Bernard. Your template seems really straight forward. The problem
I having right now is that the block that is rendered is returned via an
ognl expression and the expression is only being evaluated once. Do you
know a way around this?

On Wed, 2006-08-02 at 15:49 +0200, Bernard Lange wrote:
> Dan Adams wrote:
> > Every once in a while I'll need to do some recursive rendering. Does
> > anyone know of a simple example of this using @Block?
> 
> We do it that way. This renders tree-like, no folding though, recursive
> structure of report groups containing other report groups (which are
> compound nodes) and reports (leafs). Root group is given as a parameter,
> but it may be as well page property with initial value set to sth. You
> also need some exit condition, which in this case is size of
> reportGroups property.
> 
> Note that the group property is updated in the second loop so that the
> recursive call to "groupBlock" could render its children properly.
> 
> Some styling has been removed for a sake of readability:
> 
> **
> 
> 
> 
>   
>   
>   
>   
>  value="ognl:report" element="ul">
>   
> 
>   
> 
>   
>condition="ognl:group.reportGroups.size() > 0">
>  value="ognl:group" >
>   
> 
>  
> 
> 
> 
> 
> **
>  allow-body="no" allow-informal-parameters="no">
> 
>required="yes"
>   direction="auto"
> />
> 
> 
> 
> 
> 
> 
> best regards,
> Bernard
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
-- 
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ajax form question about Tapestry 4.1

I've been trying to avoid adding too many new parameters (like
updateComponents) all over the place before I felt like I had found a good
way to do this without code duplication.

It's probably fair that I at least add them to form/form button based
components though.

As for Forms, you could very easily use @EventListener, targeting a form +
event of "onsubmit" to get the same result. (Use ResponseBuilder to update
whatever components you want, possibly event the whole form so you see the
server side rendered validators.)

Although, if all you care about is the UI mechanism employed to decorate
form fields then you might find doing it on the client side to be more
efficient.

Perhaps I should allow an easier to use(understand?) method of decorating
form fields on the client side similar to (if not the same? will have to
think about this) the existing ValidationDelegate?

If you wanted to re-produce the "look" the server gives you could fairly
easily take the javascript reference found here -
http://tapestry.apache.org/tapestry4.1/javascript/form-validation.html - and
handle the UI part anyway you like.

If you have a Border component or similar the perfect thing to do might be
to define a javascript block like so to override the default Tapestry client
side decorating logic (not validation logic, you have to override a
different function for that):

tapestry.form.validation.handleMissingField=function(field, profile) {
  /// Do whatever you want, the default just applies a CSS class name to
the field node. You could just as easily wrap the field with a span or font
element and give it red **'s if you like
}

Can you guys log some of the things you've mentioned into JIRA so that I
don't forget? I probably won't be able to spend enough time on them (design
wise) until this weekend to implement it correctly, but may forget if no
JIRA issue has been created.

On 8/2/06, Josh Long <[EMAIL PROTECTED]> wrote:

Yeah I was sort of wondering the same thing, and in particular, how do
I get validation messages to render via ajax -- that is, i wat the
form to go through the normal validation routine and I dont want to
enable client side validation. I actually kind of like the red stars
and custom decorators the validation classes afford you...

i remember in tacos there was an example of employing the validators
(ie, led red asterisks appeared via ajax), is this possible in
tapestry 4.1 without some weird kludge?

I read in the docs that the default is to disable validation when
using submitForm -- since most of the use cases would make incurring
the validation lifecycle cumbersome to the user. Thats the default,
which implies it can be toggled... can it, and if so, how? ;-)

Thanks,

Josh

On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> Hi, I was looking at the new Tapestry 4.1 ajax features.
> EventListener/ResponseBuilder are really nice! Besides the new
annotations I
> noticed some components (such as DirectLink) already have the Tacos ajax
> functionality built in which allows you to update a certain part of the
page
> ("updateComponents" parameter), however I didn't find the same
functionality
> for the forms and submit buttons.
>
>
>
> I tried using an EventListener/ResponseBuilder combination (listening
for
> onClick and onSubmit) to try and get the same result but whenever I
click on
> a submit button the form is submitted the traditional way, the entire
page
> is reloaded. I'm guessing this could be solved by replacing the submit
> buttons with regular links and having the form submitted on the
> EventListener, but it just doesn't feel right not to use submit buttons
> where they are needed.
>
>
>
> Is there a new way to do this (maybe using the annotations) or is the
ajax
> form submit functionality just not implemented yet?
>
>
>
> Cheers
>
> Denis Souza
>
>
>
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

--
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.

Re: [ANN] WebReboot Development Server

Looks good Kevin! :)

On Wed, 2006-08-02 at 15:52 -0400, Kevin Menard wrote:
> Hi all,
> 
> In a recent thread on T5, Howard said the only thing he asked for in return
> is to see Tapestry get some exposure.  So, in that vain, I'm announcing the
> release of a small product based on Tapestry 4 here.
> 
> Briefly, we make a product called the WebReboot.  We provide an API for
> integrating the product with custom software.  Up until releasing this
> development server, the only way to program with the WebReboot was for each
> developer to have one of his own.  It was a bad situation overall.  To
> alleviate the problem we created a Tapestry-based app called the WebReboot
> Development Server [1] that emulates the hardware and lets people develop
> their applications far more easily.
> 
> Anyway, what I think is interesting about this is that rather than using
> Tapestry internally, we're distributing it for our customers to use.  So,
> people that may not even be Web developers will be running a
> Tapestry-powered application.
> 
> To be honest, going into this project, we weren't sure Tapestry was going to
> be the best fit.  Particularly, we needed fine-grain control of the URLs,
> which has traditionally been a bit of a weakness for Tapestry.  However, the
> ability to package everything up as a standalone app was a major selling
> point, beating out alternatives, such as Django.  As it turned out, we took
> care of the URLs with a simple filter and Tapestry was a perfect fit
> otherwise.  We're quite pleased with the result and hope that this release
> will somehow help the Tapestry community.
> 
> [1] http://dev.servprise.com/
> 
-- 
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[ANN] WebReboot Development Server

2006-08-02 Thread Kevin Menard

Hi all,

In a recent thread on T5, Howard said the only thing he asked for in return
is to see Tapestry get some exposure.  So, in that vain, I'm announcing the
release of a small product based on Tapestry 4 here.

Briefly, we make a product called the WebReboot.  We provide an API for
integrating the product with custom software.  Up until releasing this
development server, the only way to program with the WebReboot was for each
developer to have one of his own.  It was a bad situation overall.  To
alleviate the problem we created a Tapestry-based app called the WebReboot
Development Server [1] that emulates the hardware and lets people develop
their applications far more easily.

Anyway, what I think is interesting about this is that rather than using
Tapestry internally, we're distributing it for our customers to use.  So,
people that may not even be Web developers will be running a
Tapestry-powered application.

To be honest, going into this project, we weren't sure Tapestry was going to
be the best fit.  Particularly, we needed fine-grain control of the URLs,
which has traditionally been a bit of a weakness for Tapestry.  However, the
ability to package everything up as a standalone app was a major selling
point, beating out alternatives, such as Django.  As it turned out, we took
care of the URLs with a simple filter and Tapestry was a perfect fit
otherwise.  We're quite pleased with the result and hope that this release
will somehow help the Tapestry community.

[1] http://dev.servprise.com/

-- 
Kevin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Could really use another set of eyes for this one...

Some more info: If I do fieldset > textfield it works fine. But if I do
three nested fieldsets like: fieldset > fieldset > fieldset then when it
renders the last fieldset (or any element) it doesn't actually evaluate
the called to getBlock in the @RenderBlock. Am I missing something? Here
is basically the block that renders the fieldset:


  

  


Why would it evaluate the getBlock() expression when the second fieldset
renders but not on the third? Also, getBlock() seems to be the only
expression that *doesn't* get rendered. Does this have something to do
with parameter caching or is this something else? Is Tapestry doing
something I'm not aware of? Thanks.

On Wed, 2006-08-02 at 12:59 -0400, Dan Adams wrote:
> One of the pages in the project I'm working on basically reads an xml
> file and then dynamically builds a form at render time with a number of
> components based on the xml. And of course I'm using @Blocks to do this.
> So I have something like this (pseudotemplate):
> 
> 
>   
> 
> 
> renders a text field
> renders a property selection
> renders a checkbox
> ...
> 
> this was going fine and worked like a charm until i tried to do one that
> renders a fieldset. a fieldset may contain any number of other fields
> including other fieldsets. so no we have to handle recursion. initially,
> i tried something like this:
> 
> 
>   
> 
>   
> 
> 
> which i think works unless you try to put a fieldset within a fieldset.
> one of the problems I think is that @For caches it's parameters. so i
> moved to something like this:
> 
> 
>   
> 
> 
> and a component @RenderFieldSet:
>   
> 
>   
> 
> but I'm still having problems with the @For loop and the problem I'm
> currently having is that if you have: fieldset > fieldset > textfield
> then it appears that the binding value for renderblock is being cached
> or something. basically it renders the wrong block for the textfield
> because it's not evaluating the expression to calculate it (it's using
> the fieldset block).
> 
> Can anyone offer *any* advice or suggestions on a fix or
> different/better approach? I'm trying to find a solution to this (forget
> about an elegant solution) and I'm hitting problem after problem after
> problem. Thanks in advance. Sorry for the long email.
> 
> Also, congrats on getting 4.1 out, Jesse. :)
> 
-- 
Dan Adams
Senior Software Engineer
Interactive Factory
617.235.5857


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: how to do pagin

2006-08-02 Thread Chris Nelson

Chris should be careful to check stuff in before he
IMs people about it ;)

Should be in Trails SVN tonight for those that want
it...

--- James Carman <[EMAIL PROTECTED]> wrote:

> Are you looking to only query for the rows that you
> need?  Are you using
> Hibernate?  If so, then I need to get my
> HibernateTableModel out there
> somewhere.  OR, you can use the one that's becoming
> available in Trails.
> Chris IMed me this morning and said that he's done
> with it!  Chris, I hope I
> didn't steal your thunder or let the proverbial cat
> out of the bag.
> 
> -Original Message-
> From: Danny Mandel [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, August 02, 2006 11:56 AM
> To: Tapestry users
> Subject: Re: how to do pagin
> 
> Hi,
> 
> Take a look at contrib:table:
> 
>
http://tapestry.apache.org/tapestry4/tapestry-contrib/ComponentReference/Tab
> le.html
> 
> This will do what you want.
> 
> Danny
> 
> zqzuk wrote:
> > hi, just wondering if theres any element that
> allows auto-paging search
> > results... im using the FOR element to output
> search results btw. thank u 
> >   
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 
> 
>
-
> To unsubscribe, e-mail:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
> 
> 


__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to do pagin

2006-08-02 Thread Peter Svensson

Thar she blows!!  What's this?? Is there user servicable parts inside??

Cheers,
PS

On 8/2/06, James Carman <[EMAIL PROTECTED]> wrote:

Are you looking to only query for the rows that you need?  Are you using
Hibernate?  If so, then I need to get my HibernateTableModel out there
somewhere.  OR, you can use the one that's becoming available in Trails.
Chris IMed me this morning and said that he's done with it!  Chris, I hope
I
didn't steal your thunder or let the proverbial cat out of the bag.

-Original Message-
From: Danny Mandel [mailto:[EMAIL PROTECTED]
Sent: Wednesday, August 02, 2006 11:56 AM
To: Tapestry users
Subject: Re: how to do pagin

Hi,

Take a look at contrib:table:

http://tapestry.apache.org/tapestry4/tapestry-contrib/ComponentReference/Tab
le.html

This will do what you want.

Danny

zqzuk wrote:
> hi, just wondering if theres any element that allows auto-paging search
> results... im using the FOR element to output search results btw. thank
u
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Ajax form question about Tapestry 4.1

2006-08-02 Thread Josh Long


Yeah I was sort of wondering the same thing, and in particular, how do
I get validation messages to render via ajax -- that is, i wat the
form to go through the normal validation routine and I dont want to
enable client side validation. I actually kind of like the red stars
and custom decorators the validation classes afford you...

i remember in tacos there was an example of employing the validators
(ie, led red asterisks appeared via ajax), is this possible in
tapestry 4.1 without some weird kludge?

I read in the docs that the default is to disable validation when
using submitForm -- since most of the use cases would make incurring
the validation lifecycle cumbersome to the user. Thats the default,
which implies it can be toggled... can it, and if so, how? ;-)

Thanks,

Josh

On 8/2/06, Denis Souza <[EMAIL PROTECTED]> wrote:

Hi, I was looking at the new Tapestry 4.1 ajax features.
EventListener/ResponseBuilder are really nice! Besides the new annotations I
noticed some components (such as DirectLink) already have the Tacos ajax
functionality built in which allows you to update a certain part of the page
("updateComponents" parameter), however I didn't find the same functionality
for the forms and submit buttons.



I tried using an EventListener/ResponseBuilder combination (listening for
onClick and onSubmit) to try and get the same result but whenever I click on
a submit button the form is submitted the traditional way, the entire page
is reloaded. I'm guessing this could be solved by replacing the submit
buttons with regular links and having the form submitted on the
EventListener, but it just doesn't feel right not to use submit buttons
where they are needed.



Is there a new way to do this (maybe using the annotations) or is the ajax
form submit functionality just not implemented yet?



Cheers

Denis Souza







-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Ajax form question about Tapestry 4.1

2006-08-02 Thread Denis Souza

Hi, I was looking at the new Tapestry 4.1 ajax features.
EventListener/ResponseBuilder are really nice! Besides the new annotations I
noticed some components (such as DirectLink) already have the Tacos ajax
functionality built in which allows you to update a certain part of the page
("updateComponents" parameter), however I didn't find the same functionality
for the forms and submit buttons.

 

I tried using an EventListener/ResponseBuilder combination (listening for
onClick and onSubmit) to try and get the same result but whenever I click on
a submit button the form is submitted the traditional way, the entire page
is reloaded. I'm guessing this could be solved by replacing the submit
buttons with regular links and having the form submitted on the
EventListener, but it just doesn't feel right not to use submit buttons
where they are needed.

 

Is there a new way to do this (maybe using the annotations) or is the ajax
form submit functionality just not implemented yet?

 

Cheers

Denis Souza

Re: Localized validation messages

2006-08-02 Thread Malin Ljungh


Yeeehaa! It works :D
Thank you Firas!

TACK ;)

/Malin

On 8/2/06, Firas Adiler <[EMAIL PROTECTED]> wrote:


Hi Malin,

That's because Tapestry looks for "username-not-unique" in the properties
file bundeled with Tapestry. To override it, your
ValidationStrings.properties should have this path
{CLASS_PATH_ROOT}/org/apache/tapestry/valid/ValidationStrings.properties.

To do that:
create the package /org/apache/tapestry/valid/ under your source folder
and
place your custom ValidationStrings.properties there.


Lycka till! ;-)



-Original Message-
From: Malin Ljungh [mailto:[EMAIL PROTECTED]
Sent: Tuesday, August 01, 2006 8:24 PM
To: Tapestry users
Subject: Localized validation messages

Gah! Please save me from madness...

I've posted earlier about validation messages. I'm now stuck on getting
them
localized. I keep getting the following exception:

java.util.MissingResourceException
Can't find resource for bundle java.util.PropertyResourceBundle, key
username-not-unique


I've put a file ValidationStrings.properties in my WEB-INF but that
doesn't
help. And I can't find any documentation.

Please help :)

Malin


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Could really use another set of eyes for this one...

One of the pages in the project I'm working on basically reads an xml
file and then dynamically builds a form at render time with a number of
components based on the xml. And of course I'm using @Blocks to do this.
So I have something like this (pseudotemplate):


  


renders a text field
renders a property selection
renders a checkbox
...

this was going fine and worked like a charm until i tried to do one that
renders a fieldset. a fieldset may contain any number of other fields
including other fieldsets. so no we have to handle recursion. initially,
i tried something like this:


  

  


which i think works unless you try to put a fieldset within a fieldset.
one of the problems I think is that @For caches it's parameters. so i
moved to something like this:


  


and a component @RenderFieldSet:
  

  

but I'm still having problems with the @For loop and the problem I'm
currently having is that if you have: fieldset > fieldset > textfield
then it appears that the binding value for renderblock is being cached
or something. basically it renders the wrong block for the textfield
because it's not evaluating the expression to calculate it (it's using
the fieldset block).

Can anyone offer *any* advice or suggestions on a fix or
different/better approach? I'm trying to find a solution to this (forget
about an elegant solution) and I'm hitting problem after problem after
problem. Thanks in advance. Sorry for the long email.

Also, congrats on getting 4.1 out, Jesse. :)

-- 
Dan Adams
Software Engineer
Interactive Factory
617.235.5857


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

upgrading to 4.1 - question about concepts

2006-08-02 Thread Ron Piterman


Hi,
In an application I am currently working on (tapestry 4.0) we use 
extensivley dojo widgets and a custom ajax render cycle.


Usually the Ajax responses are rendered by a special renderer which 
wrapps components renders inside a kind of xml-rpc. This is parsed by 
java scripts and performs different actions:


It looks something like:

...
and so on.

The nice thing is, the widget that sends the request handles the 
response, so one can call from inside tapestry methods on the widgets, 
passing component render-results as parameters.


Now as far as I understand from the docu, tapestry 4.1 contains one very 
important method for ajax response: ResponseBuilder.updateComponent(...)


this will end in a replace-by-id, which is quite trivial - but what is 
the tap4.1 way of doing other things like openning a dojo dialog, 
changing status of existing widgets (and thus the under- or overlying 
html) and so on? Do I have to write javascript templates for all of 
those actions?


As far as can remember from tacos, the ajax response was also a sort of 
xml-rpc, handled by the tacos JS library. I would guess it was 
"imported" into tap4.1 - is there an overview of this somewhere? (how 
the response should look like ...) - more under the hood as in the 
existing docu?


Thanx for reading that long ;)

Cheers,
Ron


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: how to do pagin

2006-08-02 Thread James Carman

Are you looking to only query for the rows that you need?  Are you using
Hibernate?  If so, then I need to get my HibernateTableModel out there
somewhere.  OR, you can use the one that's becoming available in Trails.
Chris IMed me this morning and said that he's done with it!  Chris, I hope I
didn't steal your thunder or let the proverbial cat out of the bag.

-Original Message-
From: Danny Mandel [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, August 02, 2006 11:56 AM
To: Tapestry users
Subject: Re: how to do pagin

Hi,

Take a look at contrib:table:

http://tapestry.apache.org/tapestry4/tapestry-contrib/ComponentReference/Tab
le.html

This will do what you want.

Danny

zqzuk wrote:
> hi, just wondering if theres any element that allows auto-paging search
> results... im using the FOR element to output search results btw. thank u 
>   

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: how to do pagin

2006-08-02 Thread Danny Mandel


Hi,

Take a look at contrib:table:

http://tapestry.apache.org/tapestry4/tapestry-contrib/ComponentReference/Table.html

This will do what you want.

Danny

zqzuk wrote:

hi, just wondering if theres any element that allows auto-paging search
results... im using the FOR element to output search results btw. thank u 
  



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Auto-updating a drop-down list

2006-08-02 Thread Waimun Yeow


Jesse and Nick,

Thanks for the suggestions (1) EventListener (2) DynamicSelectionList.

I am currently using Tap 3.03 and perhaps this is a good chance to  
upgrade if I want to take advantage of 4.1 features. But I am  
concerned whether if I need to make a lot of changes to the way I  
configured the application to integrate Spring with Tapestry in  
section 15.4.2.3 at  (http://www.springframework.org/docs/reference/ 
webintegration.html).


The DynamicSelectionList is also a good option since you said it  
works with T3 (with tweaks). Perhaps you can point me to an example  
and also provide the tweaks in order for it to work.



Thanks,
waimun

RE: Date Pickers in 4.1

2006-08-02 Thread Denis Souza

Great! I'll download it and try it out. Thank you all for the replies!

-Original Message-
From: Jesse Kuhnert [mailto:[EMAIL PROTECTED] 
Sent: quarta-feira, 2 de agosto de 2006 00:22
To: Tapestry users
Subject: Re: Date Pickers in 4.1

Hi Denis,

A fix is being deployed via maven2 as I write this email. Sorry about that.

P.S. I had almost forgotten (shows how well the validation system was
written by previous contributions - I think Paul Ferraro in this case ) that
the new min/max client side validation logic ~also~ applies to the existing
DatePicker component as well. (Looks cool on the workbench demo :) )

On 8/1/06, Jesse Kuhnert <[EMAIL PROTECTED]> wrote:
>
> Hmmm...I'll look tonight, must have been a screw up on my part somehow.
> Either way it will probably be fixed by tomorrow if you are using the
> current 4.1.1-SNAPSHOT version of Tapestry with maven2. (Otherwise you can
> download the new jar manually from the snapshot repos? )
>
>
> On 8/1/06, Denis Souza <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> >
> >
> >
> > I just got Tapestry 4.1 and I now whenever I use the DatePicker
> > component
> > and click on the icon I get the following javascrip error in Firefox:
> >
> >
> >
> > Error: document.Form has no properties
> >
> > Source File: javascript:calendar_dp.toggle(document.Form.DatePicker);
> >
> >
> >
> > IE6 shows this error:
> >
> >
> >
> > 'document.Form.DatePicker' is null or not an object
> >
> >
> >
> > The javascript output seems to be in order:
> >
> >
> >
> >     > href="javascript:calendar_dp.toggle( document.Form.DatePicker);"> >
> >
src="/datetest/app?service=asset&path=%2Forg%2Fapache%2Ftapestry%2Fform%
> > 2FDatePickerIcon.png" alt="Click on icon to choose a date/time value."
> > border="0"/>
> >
> >
> >
> > I even created a new application just to test that but I keep getting
> > the
> > same error. The template code couldn't be simpler:
> >
> >
> >
> >   
> >
> >
> >
> > Any ideas on why this is happening?
> >
> >
> >
> >
> >
> >
> >
> > One other thing. I also tried to use the DropDownDatePicker component
> > but I
> > couldn't get it to work. Tapestry simply doesn't find it:
> >
> >
> >
> > Component 'DropDownDatePicker' not found in [EMAIL PROTECTED]
> > [].
> >
> >
> >
> > I'm thinking maybe something's very different about it since it's a dojo
> > widget but I haven't been able to figure out how to use it. The docs
> > don't
> > have much information about it (unless I overlooked something). Could
> > anyone
> > point me in the right direction?
> >
> >
> >
> > Thanks,
> >
> > Denis Souza
> >
> >
> >
> >
> >
>
>
> --
> Jesse Kuhnert
> Tacos/Tapestry, team member/developer
>
> Open source based consulting work centered around
> dojo/tapestry/tacos/hivemind.
>



-- 
Jesse Kuhnert
Tacos/Tapestry, team member/developer

Open source based consulting work centered around
dojo/tapestry/tacos/hivemind.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: recursive rendering

2006-08-02 Thread Bernard Lange

Dan Adams wrote:
> Every once in a while I'll need to do some recursive rendering. Does
> anyone know of a simple example of this using @Block?

We do it that way. This renders tree-like, no folding though, recursive
structure of report groups containing other report groups (which are
compound nodes) and reports (leafs). Root group is given as a parameter,
but it may be as well page property with initial value set to sth. You
also need some exit condition, which in this case is size of
reportGroups property.

Note that the group property is updated in the second loop so that the
recursive call to "groupBlock" could render its children properly.

Some styling has been removed for a sake of readability:

**

**

best regards,
Bernard

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: opening up a new windown onclick

2006-08-02 Thread zqzuk


thanks :)
-- 
View this message in context: 
http://www.nabble.com/opening-up-a-new-windown-onclick-tf2039446.html#a5613778
Sent from the Tapestry - User forum at Nabble.com.


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Announce] Clepsydra 0.8


Peter Svensson wrote:

Dang! I saw that and immediately thought it as a list of example apps that
one could look at as a newbie or for special interrests.


Clepsydra fits into those categories, I think.


Maybe it would have been better with "Success stories" or "Projects powered
by .." or something..


You mean this section?
http://wiki.apache.org/tapestry/PoweredByTapestry
Well, that's more oriented towards commercial sites.


Yes, yes, I know, I can add it... It just would feel more proper to ahve
that section under the unicorn (unicornered? :)


Well, it's a wiki ... ;-)

Cheers,
Nick.

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Announce] Clepsydra 0.8

2006-08-02 Thread Jean-Yves Sironneau


Thank you Nick.

On 8/2/06, Nick Westgate <[EMAIL PROTECTED]> wrote:

Hi Jean-Yves.

Since nobody else has complimented you yet, this looks cool.
Thanks for sharing!

Cheers,
Nick.


Jean-Yves Sironneau wrote:
> I just wanted to let you know that the first release of Clepsydra a
> GPL licensed web application for managing and sharing a collection of
> documents (pictures centric) is out.
>
> This can be a sample of Tapestry application (good or bad) as it's
> using tapestry 4.0 for all the web UI.
>
> This is for me the opportunity to say that i'am very happy with
> Tapestry, and i would like to thanks the creator and all the
> contributors for this great great framework, and for their help too.
>
> Here is the page of the project
>
> http://clepsydra.javaforge.com/
>
> Thanks
>
> Jean-Yves
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]




-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Announce] Clepsydra 0.8

2006-08-02 Thread Peter Svensson

Dang! I saw that and immediately thought it as a list of example apps that
one could look at as a newbie or for special interrests.

Maybe it would have been better with "Success stories" or "Projects powered
by .." or something..

Yes, yes, I know, I can add it... It just would feel more proper to ahve
that section under the unicorn (unicornered? :)

Cheers,
PS

On 8/2/06, Nick Westgate <[EMAIL PROTECTED]> wrote:

There is a "Sample Applications" section on the wiki.
Someone, in fact anyone, could add it there.

Cheers,
Nick.

Peter Svensson wrote:
> Yes, this should be added as a link somewhere. Couldn't someone set up a
> list on the official site with links to Tapestry powered apps? This
should
> be there.
>
> Cheers,
> PS

-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: [Announce] Clepsydra 0.8


There is a "Sample Applications" section on the wiki.
Someone, in fact anyone, could add it there.

Cheers,
Nick.


Peter Svensson wrote:

Yes, this should be added as a link somewhere. Couldn't someone set up a
list on the official site with links to Tapestry powered apps? This should
be there.

Cheers,
PS


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: opening up a new windown onclick