I know Howard appreciates the need for conversations, but he's pretty
flat-out.
Actually, I'm not sure if there's a JIRA ticket for it.
On 24/04/2008, at 7:03 AM, Christoph Jäger wrote:
Hi Geoff,
it seems your JIRA describes just what I would like to have. I
especially like the idea with
they shouldn't.
Jonathan
-Original Message-
From: Jim [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 22, 2008 10:08 PM
To: Tapestry users
Subject: Re: T5: Forms - Best Practice
Hi Christoph,
I know you're mostly asking about best-practice of process rather than
security
Hi Jim,
I like to use the primary key, because it is short and by definition
unique, and usually the quickest way to retrieve an object from the
database.
For the problem you describe, users are only allowed to view people in
their own department, three different solutions come to my
Hi Geoff,
it seems your JIRA describes just what I would like to have. I
especially like the idea with the conversation id, because my next
thought would have been: what happens if the user edits two different
persons in two different windows of his web browser at the same time
(over a
Hi,
Sorry for this long post. I spent quite some time now to try to figure
out how to use forms to edit/update objects the right way (you know,
simple, stable, elegant, easy to read, easy add things, ...). I use
Tapestry 5.0.11. I am almost satisfied with what I came up with now,
but
@Persist(flash)
http://tapestry.apache.org/tapestry5/tapestry-core/guide/persist.html
and, since I can peddle my own wares
@Persist(flashcookie)
http://wiki.apache.org/tapestry/Tapestry5HowToUsePersistentFieldStrategy
I've had one (or two) too many glasses of wine. May your night be as good as
good question, waiting for the answer too.
PS: if you attach the Autocomplete mixin to a textfield,
the onActivate called once more, if user put some data into this field.
2008/4/22, Christoph Jäger [EMAIL PROTECTED]:
Hi,
Sorry for this long post. I spent quite some time now to try to
Totally agree! See https://issues.apache.org/jira/browse/TAPESTRY-2138
Workaround is @Persist combined with nullifying the persisted object
in cleanupRender().
Geoff
http://files.doublenegative.com.au/jumpstart/
On 23/04/2008, at 6:54 AM, Christoph Jäger wrote:
Hi,
Sorry for this long
Personally i never used but may be you can use the UUID (
http://en.wikipedia.org/wiki/Universally_Unique_Identifier ) for yours
employees primary key or alternate key. They are very hard to guess.
and if you get very paranoid you can encrypt them.
César.
