Re: T5: Tapestry-Hibernate, do we have to save()?

[lasitha]

On Nov 19, 2007 5:42 PM, Thiago H de Paula Figueiredo
<[EMAIL PROTECTED]> wrote:
> On Mon, 19 Nov 2007 07:17:32 -0200, lasitha <[EMAIL PROTECTED]>
> wrote:
>
> [ a long descpription on the 'unintended save' problem ...]
>
> > On Oct 31, 2007, Thiago H de Paula Figueiredo <[EMAIL PROTECTED]> wrote:
> >
> > Thiago, any chance you'll be releasing the source [of HiberTapestry] soon?
>
> I'm planning to release the sources until this weekend.

Thiago, thanks for releasing that, i've finally had some time to look
into it this weekend.  Looks neat - well done :).

Some thoughts relevant to the 'unintended save' problem:
* I think HiberTapestry mostly solves it.
* The only hole i can see is that even though we only commit
explicitly at the successful completion of a @Transactional method, i
think it's possible that hibernate will automatically flush the
session at unexpected moments.  The default FlushMode.AUTO
documentation specifies: "The Session is sometimes flushed before
query execution in order to ensure that queries never return stale
state".  If this happens before we are ready, we may still be open to
unintentional saves.  Would it be safer to set the flush mode to
COMMIT instead?

More general feedback:
* In our own solution to the problem (see below), we found it useful
to be able to annotate page/component methods.  In fact i think our
most common case is to mark the onSuccess event as the commit point.
Since tapestry-ioc doesn't decorate pages and components, we are
contributing a ComponentClassTransformWorker that injects the
transactional code into pages.  This may be some neat functionality to
add to HiberTapestry.
* I'm not sure if https://issues.apache.org/jira/browse/TAPESTRY-1874
is still valid.  I am able to get Match("*") to work without tapestry
complaning about IOC services.  Might be something to look into as it
would elimante the naming convention limitation.

Our homegrown solution so far:
* We override and alias the HibernateSessionManager so that it always
_rolls back_ on thread cleanup.
* We set the flush mode to AUTO (also by overriding the HSM).
* We introduce a @CommitOnCompletion annotation that tells the
framework to call HSM.commit() when the marked method completes.  This
will commit the transaction that was begun when the session was first
created, and begin a new one for the rest of the request cycle.  If
the method is never called or hits an exception everything is rolled
back.

If you see any problem with that solution, please let us know.

In any case, i suspect this whole problem will be superceded by the
(hopefully) upcoming support for 'conversations'.

Be well, lasitha.

P.S.  I am leaving my current job (and considering a career change :),
so i may not do a good job of following up on this thread.  My
apologies in advance.

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

T5: Select's model

[Angelo Chen]

Hi,

I use a TreeMap for the 'Select' component, it works but it is always sorted
in the key order, not the name of country when showing to the user, i read
somewhere it can be a list, any suggestions, sample codes? thanks.

A.C.

 public TreeMap getCountryList() {return ...}




-- 
View this message in context: 
http://www.nabble.com/T5%3A-Select%27s-model-tf4930588.html#a14112599
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: T5: fixed-width Grid?

[Angelo Chen]

Hi Andy,

I can't quite understand your question, I use css to made grid fixed-width,
usually I use only one cell from the grid:

  .id-header { width:780px; }

then in the grid I can include other fields in the cell, this will not work
if you want to have sortable columns:

  
${row.id} ${row.field1} ${row.field2}
  


Andy Huhn wrote:
> 
> All,
> 
> Is there a way to make a Grid fixed-width?  That is, if it's more than x
> number of pixels, a scroll bar is rendered attached to the HTML table?
> (Not attached to the entire viewport).
> 
> Thanks,
> Andy
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 

-- 
View this message in context: 
http://www.nabble.com/T5%3A-fixed-width-Grid--tf4930497.html#a14112576
Sent from the Tapestry - User mailing list archive at Nabble.com.


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

Re: possible bug: onActivate/onDeactivate and ComponentActions

[Fernando Padilla]

The problem is that we develop with debug.  And in tapestry it prints 
out the full generated source of the page as debug, basically making the 
first few requests on the webapp totally useless as far as debug goes...


is there any way to make that source easier for us to parse out?  move 
it to TRACE or move it to a different log category easier for us to turn 
on and off?



Howard Lewis Ship wrote:

Tapestry generates warnings about any non-private fields it finds in a
component class, so you might want to keep an eye on the console as
well.

Sometimes I think console warnings are useless as no one ever seems to
see them, only by being "in your face" with a hard exception can you
catch the developers' attention.

On Dec 1, 2007 11:17 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote:

Yeah, they were public. Making all my variables private is one of those
things I do without thinking, and I forgot to check that in this case.

Funny.  I don't remember reading about tapestry setting all private
variables to null (or their default values) in the docs.  Maybe I
skimmed that part of the docs when I read them a while back.

My apologies, setting them to private and having Tapestry set them to
null should take care of it then.



Howard Lewis Ship wrote:

What possible state would you have to clean up?

Assuming you are using proper instance variables (all private), then
Tapestry already does end-of-request cleanup, resetting all your
fields to correct default values (for those that are not set to fixed
values via an injection).

On Nov 30, 2007 6:34 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:

The bug we're seeing is that the page context is being set by an
onActivate call, but it's never being cleaned up.  So the next page
render still has the old page context setup, and we don't have a chance
to re-null it.



normally while handling a page:

onActivate
setupRender
...
cleanupRender

We can absorb the context and cleanup anything that needs to be cleaned
up within the "cleanupRender".  But for ComponentActions, there is no
such "cleanup" method available:

onActivate
onAction



Proposed solution is really easy, just add an "onDeactivate" event.
Allowing us to undo any page activation.


ideas?



-
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]

T5: fixed-width Grid?

[Andy Huhn]

All,

Is there a way to make a Grid fixed-width?  That is, if it's more than x
number of pixels, a scroll bar is rendered attached to the HTML table?
(Not attached to the entire viewport).

Thanks,
Andy

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

Re: possible bug: onActivate/onDeactivate and ComponentActions

[Andy Huhn]

I think console warnings are a great thing, and I hope you're not
thinking about doing away with them!  Maybe it's just because I'm a
newbie, but I comb through those logs looking for problems if I get any
unexpected behavior.

Thanks,
Andy

On Sat, 2007-12-01 at 11:54 -0800, Howard Lewis Ship wrote:
> Tapestry generates warnings about any non-private fields it finds in a
> component class, so you might want to keep an eye on the console as
> well.
> 
> Sometimes I think console warnings are useless as no one ever seems to
> see them, only by being "in your face" with a hard exception can you
> catch the developers' attention.
> 
> On Dec 1, 2007 11:17 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> > Yeah, they were public. Making all my variables private is one of those
> > things I do without thinking, and I forgot to check that in this case.
> >
> > Funny.  I don't remember reading about tapestry setting all private
> > variables to null (or their default values) in the docs.  Maybe I
> > skimmed that part of the docs when I read them a while back.
> >
> > My apologies, setting them to private and having Tapestry set them to
> > null should take care of it then.
> >
> >
> >
> > Howard Lewis Ship wrote:
> > > What possible state would you have to clean up?
> > >
> > > Assuming you are using proper instance variables (all private), then
> > > Tapestry already does end-of-request cleanup, resetting all your
> > > fields to correct default values (for those that are not set to fixed
> > > values via an injection).
> > >
> > > On Nov 30, 2007 6:34 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> > >> The bug we're seeing is that the page context is being set by an
> > >> onActivate call, but it's never being cleaned up.  So the next page
> > >> render still has the old page context setup, and we don't have a chance
> > >> to re-null it.
> > >>
> > >>
> > >>
> > >> normally while handling a page:
> > >>
> > >> onActivate
> > >> setupRender
> > >> ...
> > >> cleanupRender
> > >>
> > >> We can absorb the context and cleanup anything that needs to be cleaned
> > >> up within the "cleanupRender".  But for ComponentActions, there is no
> > >> such "cleanup" method available:
> > >>
> > >> onActivate
> > >> onAction
> > >>
> > >>
> > >>
> > >> Proposed solution is really easy, just add an "onDeactivate" event.
> > >> Allowing us to undo any page activation.
> > >>
> > >>
> > >> ideas?
> > >>
> > >>
> > >>
> > >> -
> > >> 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: Single OGNL expression evaluated several times ­ is it normal?

[Kevin Menard]

This is a known issue and is pending resolution.


On 12/1/07 9:29 AM, in article
[EMAIL PROTECTED], "Kaspar Fischer"
<[EMAIL PROTECTED]> wrote:

> Hi,
> 
> My Page.html contains a single Tapestry component:
> 
>Title
> 
> Why is my page's method getTitle() executed several times?
> 
>15:23:11,106 User:admin DEBUG [knowledgecenter.pages.NodePage]
> NodePage.pageBeginRender().
>15:23:11,188 User:admin DEBUG [knowledgecenter.pages.NodePage]
> NodePage.getTitle().
>15:23:11,204 User:admin DEBUG [knowledgecenter.pages.NodePage]
> NodePage.getTitle().
>15:23:11,244 User:admin DEBUG [knowledgecenter.pages.NodePage]
> NodePage.getTitle().
>15:23:11,377 User:admin DEBUG [knowledgecenter.pages.NodePage]
> NodePage.pageEndRender().
> 
> Is this normal or have I misconfigured Tapestry in some way?
> 
> Kaspar
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 

-- 
Kevin Menard
Servprise International, Inc.
Remote reboot & power control for network equipment
www.servprise.com  +1 508.892.3823 x308



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

Re: T4: From the client side, how do you programmatically update a component?

[Kalle Korhonen]

No - I want to trigger the update programmatically via Javascript, not from
a user's click.

Kalle


On 12/1/07, Ulrich Stärk <[EMAIL PROTECTED]> wrote:
>
> I can't follow you. You want a component to update itself asynchronously
> upon a user's click on a DirectLink? Why don't you just use DirectLink's
> updateComponents parameter with async="true"?
>
> Uli
>
> Kalle Korhonen schrieb:
> > I have a use case where I need to "click on" a directllink to
> > updatecomponents with async=true or do an equivalent action in
> Javascript. I
> > know I can do tapestry.bind('') and it makes
> > some sense, but looks rather ugly. Any cleaner way to accomplish this?
> >
> > Kalle
> >
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>

Re: T4: From the client side, how do you programmatically update a component?

[Ulrich Stärk]

I can't follow you. You want a component to update itself asynchronously 
upon a user's click on a DirectLink? Why don't you just use DirectLink's 
updateComponents parameter with async="true"?


Uli

Kalle Korhonen schrieb:

I have a use case where I need to "click on" a directllink to
updatecomponents with async=true or do an equivalent action in Javascript. I
know I can do tapestry.bind('') and it makes
some sense, but looks rather ugly. Any cleaner way to accomplish this?

Kalle




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

Re: possible bug: onActivate/onDeactivate and ComponentActions

[Howard Lewis Ship]

Tapestry generates warnings about any non-private fields it finds in a
component class, so you might want to keep an eye on the console as
well.

Sometimes I think console warnings are useless as no one ever seems to
see them, only by being "in your face" with a hard exception can you
catch the developers' attention.

On Dec 1, 2007 11:17 AM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> Yeah, they were public. Making all my variables private is one of those
> things I do without thinking, and I forgot to check that in this case.
>
> Funny.  I don't remember reading about tapestry setting all private
> variables to null (or their default values) in the docs.  Maybe I
> skimmed that part of the docs when I read them a while back.
>
> My apologies, setting them to private and having Tapestry set them to
> null should take care of it then.
>
>
>
> Howard Lewis Ship wrote:
> > What possible state would you have to clean up?
> >
> > Assuming you are using proper instance variables (all private), then
> > Tapestry already does end-of-request cleanup, resetting all your
> > fields to correct default values (for those that are not set to fixed
> > values via an injection).
> >
> > On Nov 30, 2007 6:34 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> >> The bug we're seeing is that the page context is being set by an
> >> onActivate call, but it's never being cleaned up.  So the next page
> >> render still has the old page context setup, and we don't have a chance
> >> to re-null it.
> >>
> >>
> >>
> >> normally while handling a page:
> >>
> >> onActivate
> >> setupRender
> >> ...
> >> cleanupRender
> >>
> >> We can absorb the context and cleanup anything that needs to be cleaned
> >> up within the "cleanupRender".  But for ComponentActions, there is no
> >> such "cleanup" method available:
> >>
> >> onActivate
> >> onAction
> >>
> >>
> >>
> >> Proposed solution is really easy, just add an "onDeactivate" event.
> >> Allowing us to undo any page activation.
> >>
> >>
> >> ideas?
> >>
> >>
> >>
> >> -
> >> 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]
>
>



-- 
Howard M. Lewis Ship
TWD Consulting, Inc.

Creator Apache Tapestry and Apache HiveMind

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

Re: possible bug: onActivate/onDeactivate and ComponentActions

[Fernando Padilla]

Yeah, they were public. Making all my variables private is one of those 
things I do without thinking, and I forgot to check that in this case.


Funny.  I don't remember reading about tapestry setting all private 
variables to null (or their default values) in the docs.  Maybe I 
skimmed that part of the docs when I read them a while back.


My apologies, setting them to private and having Tapestry set them to 
null should take care of it then.



Howard Lewis Ship wrote:

What possible state would you have to clean up?

Assuming you are using proper instance variables (all private), then
Tapestry already does end-of-request cleanup, resetting all your
fields to correct default values (for those that are not set to fixed
values via an injection).

On Nov 30, 2007 6:34 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:

The bug we're seeing is that the page context is being set by an
onActivate call, but it's never being cleaned up.  So the next page
render still has the old page context setup, and we don't have a chance
to re-null it.



normally while handling a page:

onActivate
setupRender
...
cleanupRender

We can absorb the context and cleanup anything that needs to be cleaned
up within the "cleanupRender".  But for ComponentActions, there is no
such "cleanup" method available:

onActivate
onAction



Proposed solution is really easy, just add an "onDeactivate" event.
Allowing us to undo any page activation.


ideas?



-
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]

T4: From the client side, how do you programmatically update a component?

[Kalle Korhonen]

I have a use case where I need to "click on" a directllink to
updatecomponents with async=true or do an equivalent action in Javascript. I
know I can do tapestry.bind('') and it makes
some sense, but looks rather ugly. Any cleaner way to accomplish this?

Kalle

Single OGNL expression evaluated several times – is it normal?

[Kaspar Fischer]

Hi,

My Page.html contains a single Tapestry component:

  Title

Why is my page's method getTitle() executed several times?

  15:23:11,106 User:admin DEBUG [knowledgecenter.pages.NodePage]  
NodePage.pageBeginRender().
  15:23:11,188 User:admin DEBUG [knowledgecenter.pages.NodePage]  
NodePage.getTitle().
  15:23:11,204 User:admin DEBUG [knowledgecenter.pages.NodePage]  
NodePage.getTitle().
  15:23:11,244 User:admin DEBUG [knowledgecenter.pages.NodePage]  
NodePage.getTitle().
  15:23:11,377 User:admin DEBUG [knowledgecenter.pages.NodePage]  
NodePage.pageEndRender().


Is this normal or have I misconfigured Tapestry in some way?

Kaspar

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