Without addressing the specifics of the design issue, whether or not to use
POs, our experience here of Tap 4 is that it is highly maintainable. One of
the issue affecting maintanability is where things are found. My
understanding is that the design choice is between implicit and declared
componen
Thanks Jesse.
I know that I would have more trouble than formatting if I migrate from a
web app to a desktop app, but I would like to minimize that effort.
However there's a 0.001 probability this app will ever be migrated, I was
just asking theoretically. (I could have said Struts instead of Swi
I think you're going to have a lot more trouble with migration from a web
application to a desktop application than just formatting
I'd focus on making your core functionality separate enough as standalone
services and use that as the basis for migrate-able code and not focus in on
making you
But doesn't that reduce code resusability?
I mean if tomorrow I have to migrate the app to Swing, i have to reformat
everything.
On 6/24/07, Ulrich Stärk <[EMAIL PROTECTED]> wrote:
Use the format parameter of the insert component. You can supply an
insert component that displays a Date object
Use the format parameter of the insert component. You can supply an
insert component that displays a Date object with a custom
java.text.DateFormat to display the date the way you want.
Uli
Marcos Chicote schrieb:
i see what you mean Christian.
In this design if you have to show a Date, how d
i see what you mean Christian.
In this design if you have to show a Date, how do you convert it? I mean, if
you let Tapestry do date.toString() this will probably show a lot of things
you don't want. Do you use a property in the java file where you put
something like dateToString(yourDate) that do
Hello,
Christian Dutaret a écrit :
...
I have some web non-regression tests that check for the correctness of
the
ognl expressions. That has worked fine for me so far.
Please, can you tell us how do you implement "web non-regression tests" ?
Which tools ? Which methods ?
Thanks a lot
cyrille
Marcos,
The concept of a presentation object model has a strong smell of bad design:
double hierarchy maintenance and transformation methods from/to both models
which are very error-prone. If you forget to assign a field in those
transformation methods, you can spend hours searching for the descr
Thanks Ulrich!
I was also considering that.
Whath do you think about BO in the presentation layer?
I think the correct solution would be to use Presentation Object and do the
getDepartamentChief().getName() there. I believe POs should not know about
the presentation layer, so my solution would b
Marcos,
You should also consider that when traversing the object tree with ognl you might run into runtime
exceptions when you change for example the name of a getter and forgot to adjust your ognl
expression. If you did that navigation in the page class the compiler would warn you of a
non-ex
Thanks Marcus!
I know Tapestry will implement the method for me, and that both ways work.
The question is which of those would you use? Is anyone better from a design
point of view than the otherone? Are they the same?
The problem is that if, for example, some day Users BO is no longer of use,
an
http://tapestry.apache.org/tapestry4/tapestry/ComponentReference/Insert.html
or
http://tapestry.apache.org/tapestry4 in menu Fremawork -> Components
Hi Marcos,
In template Html:
in Java class:
public abstract Department getDepartment();
Tapestry will implement this method for you.
Marcus
13 matches
Mail list logo
