I am a sole developer on my project, and I am also using Fernando's
approach. The "form beans" help solve order of data entry and other
dependencies that I just wouldn't want to encode in the persistent
model. In addition, I've found these "form beans" are a great way to
insert hard coded data and do testing.
i.e.
public void generateSampleReportingUsers() {
Registration r = new Registration();
r.setUsername("daniel.jue");
r.setPassword("urshipmentofFAILhasarrived");
r.setFirstName("Daniel");
r.setMiddleInitial("");
r.setLastName("Jue");
r.setInstallationAccess("DEMO");
r.setDatabaseAccess("DEMO");
...
...
this.addReportingUser(r);
}
On Wed, May 28, 2008 at 4:43 PM, Fernando Padilla <[EMAIL PROTECTED]> wrote:
> The design pattern that we are starting to play with is to create beans
> specifically for the forms. Then write code that ferries the data between
> the form-bean and the actual persistent objects.
>
> This gives you more grunt work, but it adds a point of abstraction and
> flexibility. For the most part it gives you freedom to construct your
> form/ui differently than the underlying persistent model. For example, all
> validator/data type annotations are tied to the form-bean instead of the
> underlying persistent model, which might not match cleanly. Also your
> persistent model might not be what you actually want to expose to the form.
> Or you can expose a more complicated form which maps to persistent model in
> different ways (multiple objects, etc etc).
>
> At the moment, it's not as "easy" as just giving the bean edit form your
> persistent objects, but I think it's more flexible in the long run. So it's
> just another option to keep in mind. You just have to keep your form-beans
> outside of the components/pages packages or you'll have issues with the
> tapestry enhancing classloaders.. We keep them under a forms package..
>
>
> Filip S. Adamsen wrote:
>>
>> Well, you're right. But to me, at least, it's not that big of a deal. The
>> dependency will be to tapestry5-annotations, which is a very small
>> dependency.
>>
>> Anyhow, developing Tapestry apps is just a hobby of mine - for now, anyhow
>> - so I make the decisions myself.
>>
>> Sadly, I don't know of any other way to specify which constructor to use.
>> I suggest you raise a JIRA issue if you want an alternative way to do it.
>>
>> -Filip
>>
>> On 2008-05-28 20:13, José Paumard wrote:
>>>
>>> Hello Filip,
>>>>
>>>> From what I understand, that would involve changing the object model
>>>
>>> (not so nice, I dont have the hand on that), and making a dependency
>>> from this model to T5. I can already hear ppl screaming at that ;)
>>>
>>> Am I right ?
>>> Thank you,
>>>
>>> José
>>>
>>> Filip S. Adamsen a écrit :
>>>>
>>>> Hi José,
>>>>
>>>> You can put @Inject in the constructor you want Tapestry to use for
>>>> auto-instantiation. Should solve your problem.
>>>>
>>>> -Filip
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
