Thanks, Kalle. I'll look into Tacos.
You're right about 0.4.3. It has worked extremely well for me too. But
I've run into a serious problem with event.connect that is most likely a
bug. I don't want to get into what I suspect will be extremely
time-consuming debugging against such an old vers
http://tapestry.apache.org/tapestry5/tapestry-core/guide/rendering.html
On Tue, Jul 22, 2008 at 5:19 AM, Toby Hobson <[EMAIL PROTECTED]>
wrote:
> Hi
>
> Could anyone tell point me to some docs about T5's component lifecycle? I
> know there are methods like pageLoaded and onActivate available to p
Hi
Could anyone tell point me to some docs about T5's component lifecycle? I know
there are methods like pageLoaded and onActivate available to pages, I wondered
if there was something similar for components
Thanks
Toby
Hi,
Why would you use a chain of command for this kind of thing? If all you
need to do is look up some object by a key then a regular service should
suffice, no?
public interface OrganizationBlockSource {
Block getOrganizationBlock(OrganizationType type);
}
You could then look up a page,
One of my domain data types (organization) will be endowed with a type
label (an enum). Each different type will need to have, on the page
that views the organization, a block that is dependent on that type.
These blocks are large and quite complex, so I don't want to define
those blocks in the vi
That, or just add @Cached to getItems.
-Filip
On 2008-07-21 20:48, Howard Lewis Ship wrote:
Yes, and perhaps adding a SetupRender render phase method to setup a
temporary list with the values to iterate over.
On Mon, Jul 21, 2008 at 10:42 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote:
Hi,
O
Tacos already does Dojo 1.0.2 integration almost out-of-the-box (
http://tacos.sourceforge.net/tacos4.1/tacos-dojo/index.html). If you need
1.1, you could probably just follow the Tacos source and do the same, or
better yet, contribute dojo 1.1 integration back to Tacos.
What features of Dojo 1.1
I think the basic pieces of BeanEditForm could be reused to build a
component such as the one you describe. The BeanEditForm is not
intended as the be-all and end-all of user input; it's supposed to
supply useful scaffolding at the beginning of a project and, for
critical forms with complex layout
Yes, and perhaps adding a SetupRender render phase method to setup a
temporary list with the values to iterate over.
On Mon, Jul 21, 2008 at 10:42 AM, Filip S. Adamsen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> On 2008-07-21 17:49, margi wrote:
>>
>> That's what I did finally! You're right about the fac
Hi,
I have a small LoginBox component on all of my public pages. If credentials
are entered okay, the users logs in. No problem here.
If the credentials are wrong however, I want the user to be forwarded to a
full LoginPage that shows the validation errors and the LoginBox component
so the user c
Hi,
On 2008-07-21 17:49, margi wrote:
That's what I did finally! You're right about the fact that we're not
supposed to have logic in template, but personnaly I think there as some
logics that don't worth a Getter. Imagine if my list contains 10 elements
through which I have to iterate, I'd be
Em Mon, 21 Jul 2008 12:49:43 -0300, margi <[EMAIL PROTECTED]> escreveu:
That's what I did finally! You're right about the fact that we're not
supposed to have logic in template, but personnaly I think there as some
logics that don't worth a Getter. Imagine if my list contains 10 elements
throug
>
> Imagine if my list contains 10 elements
> through which I have to iterate, I'd be oblige to write 10 getters,
>
I would say that a design that is pulling items from a list like this is
questionable. I would be curious to hear of a real world example where this
is the best solution.
Josh
On M
Thiago, you are completely right, but I think sometimes we cannot
avoid to make simple tests or pass some arguments to a method... I try
not to use it too much, but sometimes it makes my life easier. This is
actually a major issue for me.
On Mon, Jul 21, 2008 at 12:49 PM, margi <[EMAIL PROTECTED]>
That's what I did finally! You're right about the fact that we're not
supposed to have logic in template, but personnaly I think there as some
logics that don't worth a Getter. Imagine if my list contains 10 elements
through which I have to iterate, I'd be oblige to write 10 getters, I really
thi
Em Mon, 21 Jul 2008 11:22:31 -0300, margi <[EMAIL PROTECTED]> escreveu:
retrieve one element whose index I know. In T4 I'd invoke
myList.getItem(index). I've tried ${myList.getItem(index)}, b ut didn't
work. I'd appreciate if someone can tell me what I miss or the way to do
Try creating a gett
Hi margi,
This is a known issue, marked to be solved to 5.1 version. see
https://issues.apache.org/jira/browse/TAPESTRY-1624
I believe this feature was removed because of the bottleneck created
by the use of OGNL to evaluate those expressions. Tapestry uses a very
own solution that right now is no
Hi,
I had this Exception once as I created a small app which would check through
a database and send some emails. First try I multithreaded it too much, and
indeed, the main method would be long finished and closed, shutting down the
IOC Registry with it, before all the emailing was done (which ne
Thanks Howard,
pity though.
*some rambling:*
I didn't have enough time to dig into the
BeanEditForm/BeanEditor/PropertyEditor thing far enough to unearth the
workings of the thing, otherwise i'd like to have tried
overriding the usual parameter with my own parameter so it could take
another att
Hi to All,
After working for a while with T4, I now decided to start migrating to T5.
But since the begining of that project I'm missing one of the T4 features
that I really appreciate. Which the possibility to invoke in the HTML (now
TML), some of the java methods other than the getters and liste
Em Mon, 21 Jul 2008 06:00:33 -0300, <[EMAIL PROTECTED]> escreveu:
Can someone please explain why "t:" is required for parameters and, if
that is the case, why is it missing in examples in the Tutorial?
AFAIK, t: exists to clearly differentiate what is a component parameter
from what is an H
Sorry about the action link. The correct form is:
:)
On Mon, Jul 21, 2008 at 9:07 AM, Marcelo Lotif <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I don't clearly understand the use of the "t:" prefix (anyone can
> correct me if I am wrong), but I think that's a good practice to
> always use it when decla
Hi,
I don't clearly understand the use of the "t:" prefix (anyone can
correct me if I am wrong), but I think that's a good practice to
always use it when declaring a "t:type" and "t:id" parameters, like in
For the other parameters, this is not necessary(i.e. declaring
"t:page" or "page" has the s
Hi Richard,
I'll be very interested in co-operating to have a dojo-1.x
implementation. In my opinion at the moment being stuck with dojo
0.4.3 is the only big tapestry 4 pitfall.
Martino
On Mon, Jul 21, 2008 at 11:50 AM, Richard Hoberman
<[EMAIL PROTECTED]> wrote:
>
> I'm considering upgrading t
I'm considering upgrading to the latest Dojo library using the mechanism
described at:
http://tapestry.apache.org/tapestry4.1/ajax/beyonddojo.html
Has anyone managed to use this? How time-consuming was it? Does anyone
have an implementation they'd be willing to share? If not, how much
interes
I am using the new book on Tapestry 5 by Alexander Kolesnikov and I
notice that there is a subtle difference between the Tapestry web
Tutorial and what is in the book:
that is the case, why is it missing in examples in the Tutorial?
Also, where is there anywhere I can see what tags are defi
26 matches
Mail list logo
