Reuse Edit/Create for Query by Example
Search is next step from the following thread whereby an UPDATE form may be
REUSED to ADD a database record:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-td5643323.html
The same form should do Query By Example (QBE) supported as by Hibernate:
http://docs.jboss.org/hibernate/orm/4.1/manual/en-US/html/ch17.html#querycriteria-examples
So the same exact form is now used to ADD, UPDATE or QBE.
For the sake of completeness, here is EditPerson from
http://tapestry.apache.org/hibernate-user-guide.html
modified for dual service as Edit/Create
public class EditPerson
{
@Inject
private Session session;
@PageActivationContext
@Property
private Person person;
@InjectPage
private Persons persons;
void onActivate(Person person)
{
this.person = person;
}
Object onPassivate() { return person; }
@CommitAfter
Object onSuccess()
{
session.saveOrUpdate(person);
return persons;
}
}
Persons.java is simply doing listing
public class Persons
{
@Property
private Person person;
@Inject
private Session session;
public ListPerson getPersons()
{
return session.createCriteria(Person.class).list();
}
}
Corresponding tmls are:
EditPerson: t:beaneditform object=person /
Persons: t:grid source=persons /
which are inserted between the usual
html t:type=layout title=Persons
xmlns:t=http://tapestry.apache.org/schema/tapestry_5_3.xsd;
xmlns:p=tapestry:parameter
/html
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-for-Query-by-Example-tp5655916p5655916.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create for Query by Example
To do QBE, I would simply modify the getPersons method in Persons.java
public ListPerson getPersons()
{
return session.createCriteria(Person.class).add( Example.create(person)
).list();
}
This would use the person property to list persons list. Of course, I would
check for person=nulls etc to protect the above and list all if so...the
above is just to simplify.
However, the input form needs another button in addition to Create/Update.
Lets say I even manually add it - and call it Search.
How does the EditPerson NOT end up creating a new Person? In the Struts
world this would simply be a search method within same PersonAction class.
And the same Person object on the Valuestack would be used as an Hibernate
Example to drive search instead of ending up as parameter of AddPerson and
creating a new record.
And so on..., generally, how does one single form submit be wired to support
multiple actions? Or is this frowned upon as bad practice?
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-for-Query-by-Example-tp5655916p5655931.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create for Query by Example
Most likely, the solution is to simply segregate Search (QBE) from Create/Update using EventLink. That is, segregate the Search workflow instead of overloading Create/Update. This is to bypass the (default?) onSuccess and therefore prevent the EditPage from Adding a Person instead of doing QBE. # QBE Search To style this as a Search BUTTON instead of a link, use ChenilleKit as in: http://jumpstart.doublenegative.com.au/jumpstart/examples/styling/linksandsubmits1 -- View this message in context: http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-for-Query-by-Example-tp5655916p5656016.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create for Query by Example
Instead of eventlinks and the ch kit wrapper for button...just use: t:submit t:id=search value=QBE Search / http://tapestry.apache.org/current/apidocs/index.html?org/apache/tapestry5/corelib/components/EventLink.html -- View this message in context: http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-for-Query-by-Example-tp5655916p5656051.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
On Mon, 16 Apr 2012 23:50:16 -0300, netdawg net.d...@yahoo.com wrote: Thanks, Thiago. :) I think I understand the logic/strategy: If there's a context value passed, it is the id of an object to be edited. If not, we're going to create a new object. In the above code, just changing @Persist(entity) to @PageActivationContext seems to achieve that I guess so. I haven't used @PageActivationContext yet, but it does seem to do the trick. Is that all? Yes! This is something that happens often here in this list: someone thinking that something in Tapestry would be more complicated that it really is. :) -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Reuse Edit/Create
How to reuse the EditPerson from
http://tapestry.apache.org/hibernate-user-guide.html as also create.
public class EditPerson
{
@Persist(entity)
@Property
private Person person;
@InjectPage
private PersonIndex personIndex;
void onActivate(Person person)
{
this.person = person;
}
Object onPassivate() { return person; }
@CommitAfter
Object onSuccess()
{
return personIndex;
}
}
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-tp5643323p5643323.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
Replacing @Persist(entity) with @PageActivationContext seems to do the
trick.
There was also talk of creatively coding the onActivate method starting with
version 5.3.
Of course, the onSuccess() is modified to
@CommitAfter
Object onSuccess()
{
session.saveOrUpdate(person); // rather than just persist
return personIndex;
}
Just curious what the best (new) practice is for this common design pattern
of Add/Update being driven by the same page/class etc.
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-tp5643323p564.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
On Mon, 16 Apr 2012 06:20:28 -0300, netdawg net.d...@yahoo.com wrote: Just curious what the best (new) practice is for this common design pattern of Add/Update being driven by the same page/class etc. I've been using it since my Struts (aaargh!) days and it works very, very well in Tapestry too. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
Thanks, Thiago. I am not sure I understand, though. Let me clarify. Here is a another thread that brought up this subject with a rather elaborate (unnecessary) workaround: http://tapestry.1045711.n5.nabble.com/Using-the-same-page-for-edit-new-Solution-td4876281.html Howard Lewis Ship wrote I recently changed Tapestry 5.3 so that the Hibernate ValueEncoder (used implicitly by @PageActivationContext) will encode a transient entity as null. This makes it possible to use the same page for add and edit, with *a bit of smart logic in your onActivate() event handler method/br. In the above EditPerson class from Tapesrty-Hibernate tutortial, I was able to replace @Persist(entity) with @PageActivationContext and get it to work, apparently. Still somewhat mystified, though, about the smart logic needed within onActivate()...what am I missing...?? In other words, if you could modify the EditPerson class to service a form input that is both Add and Update, what smart coding would you do in onActivate and why? And, for the benefit of the community, can we declare that as a standard/best practice for this common design pattern of Edit/Create form? If not, what would that practice be, if that can be articulated? Hope that is clear. Thanks, again, for your time. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-tp5643323p5645309.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
On Mon, 16 Apr 2012 22:14:35 -0300, netdawg net.d...@yahoo.com wrote: In other words, if you could modify the EditPerson class to service a form input that is both Add and Update, what smart coding would you do in onActivate and why? If there's a context value passed, it is the id of an object to be edited. If not, we're going to create a new object. And, for the benefit of the community, can we declare that as a standard/best practice for this common design pattern of Edit/Create form? I don't think we need to define a best practice in this case. I just think the code and template for editing and creating a new object so similar that using different pages for them ends up using copied code or a shared subclass, and that can be avoided. -- Thiago H. de Paula Figueiredo Independent Java, Apache Tapestry 5 and Hibernate consultant, developer, and instructor Owner, Ars Machina Tecnologia da Informação Ltda. http://www.arsmachina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Reuse Edit/Create
Thanks, Thiago.
I think I understand the logic/strategy: If there's a context value
passed, it is the id of an object to be edited. If not, we're going to
create a new object. In the above code, just changing @Persist(entity)
to @PageActivationContext seems to achieve that
Is that all? I guess my question was WHAT ELSE needs to be done to get this
production ready? Howard's quote seems to suggest something smart needed
within the onActivate method. I suppose the only thing needed in onActivate
is this.person = person; (???)
void onActivate(Person person)
{
this.person = person; // is this the only smart thing needed in
onActivate?
}
Is that all, or is there something else?
By now, I am almost convinced the answer is: YES, that is all that is
needed...(but just wanted to make absolutely sure about this, so I don't end
up with something flaky just because I did not do the intended smart thing
within onActivate()...;-)
Thanks again...and, please bear with me as I learn to adjust to Code less,
deliver more...
--
View this message in context:
http://tapestry.1045711.n5.nabble.com/Reuse-Edit-Create-tp5643323p5645453.html
Sent from the Tapestry - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
