[Tapestry Central] Why chose Tapestry?

[Howard <hl...@gmail.com>]

I recently had an e-mail exchange with a Tapestry user; after
congratulating me on creating Tapestry, he went on with the following
observation on his organization: The company I work at unfortunately
chose JSF for their big app. The reason was that Tapestry was "brittle"
in the sense that, if one developer breaks something, on a page or a
service, very often the whole site won't come up because the initial
registry startup will fail. Or for example, if page A has a pagelink to
page B, and page B is broken, then page A won't render. While I agree
that we shouldn't ship unless the whole app is working, this is a
thousands of pages big app with hundreds of mediocre (as in likely to
break things) developers. They'd rather have 80% of the thing working
than nothing at all. I never thought of this for my own projects, and
haven't had the time to examine the truth of their claims. What's your
take?
I provided the following response:
Early failures are absolutely, 100%, the only path towards code
quality. You may have heard the phrase "no broken windows" (see "The
Tipping Point" by Malcom Gladwell for more details) but the short form
is that when errors go uncorrected (whether they are broken windows in
an abandoned building, or broken code in an application) they tend to
multiply quite rapidly.
The things that will "break" a link from page A to page B are
substantial problems such as invalid templates, references to unknown
properties or components, or compile errors in the page B class ...
things that no other developer should ever see when page B's developer
is working and checking in code. That is, problems that should never be
checked into trunk, but instead kept in a local workspace or a private
branch.
An organization that thinks that fail early is a problem is an
organization that isn't prepared to develop a large application in any
technology. The image I'm getting is one where there is no build
server, no continuous integration, at best CVS for source code
management (or possibly one of those "shared directory"
monstrosities) .... i.e., a chaotic environment where errors are
allowed to be checked in to the trunk and can go unnoticed for some
time.
The solution to coding errors in pages or components is not to wait
until your testers (or end users) find the bugs, but to identify and
fix the bugs early. That's called "engineering discipline" and the
reality is that even self-professed "mediocre" developers can do it.
Tapestry helps because it fails early and has great exception reporting
to guide you right the problem so that you can fix it.
Another factor here is enforced helplessness. If only Fred understands
page B and he's out when it's broken, then all development stops
waiting for Fred to get back. I hit this problem myself, years ago
working on a large Struts application (those words give me the heebie
jeebies now!). We had lots of code, a fragile and slow build process,
and many little code "fiefdoms". I spent too much wasted time twiddling
my thumbs.
Nobody should "own the code"; if page B is is broken, Julie (who
normally develops page A) should be free to fix it. Julie will need to
understand the page B code well enough to fix it, but also you need an
overall environment with shared source, no repository locks (that is,
nothing that says "Only Fred can change this file"), and no management
PHB's getting in the way. Pair programming is the best way for Fred and
Julie to share knowledge so that they can understand each other's code.
Even if pairing occurs only part time, it's very effective at knowledge
transfer as well as ordinary coding.
The idea that "mediocre" developers should use JSF as it is more
tolerant of errors is absurd! Tapestry 5 is designed to improve
productivity for all developers, by streamlining, simplifying, being
smart and being concise ... not to mention live class reloading and
best-of-breed exception reporting, which makes it fast to identify and
fix those errors.
If your doctor tells you to eat less red meat, that doesn't mean you
should switch to a diet of fried chicken three meals a day! Likewise,
if you have concerns with code quality from your developers, you should
not switch to a less agile, more code-intensive, less supportive
development model and hope to catch all the bugs in QA. Sweeping
problems under the rug is never a winning strategy.
Coming down off my soap box, I should also add that Tapestry 5.1 works
a little bit differently than 5.0 in this respect, so it does (in fact)
defer more of the page loading and validation until a link is actually
clicked. This is more for performance reasons than to shield developers
from application problems. Even in 5.0, the loading and validation was
the "reach" from page A to pages explicitly referenced (usually via
PageLink during the rendering of page A), so it's a highly unlikely
case that a single error in a 1000 page application will keep the
application from starting up, unless the start page of the application
links to all 999 other pages.
Re-reading the above post I can't emphasize enough: you can't ignore
quality problems. Quality problems lead to development failures,
schedule slips, missing functionality, low morale and high turnover.
Saying "we don't have time to fix the quality problem first" is to
ignore the the second law of Thermodynamics. You are expecting a
miracle, literally writing it into your project plan.
Formos addresses this issue two ways: First, we use Scrum and deliver
on (typically) 4 week cycles. Thus we set real deadlines and have a
constant check on quality (we're providing working code constantly). We
don't even try to predict what we'll be doing six months or two years
from now, we just deliver a steady, manageable stream of software.
Secondly, Formos uses Tapestry because of all the reasons that the
anonymous developer's organization rejected it, and for many, many more
reasons besides.

--
Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM

Re: [Tapestry Central] Why chose Tapestry?

[Olle Hallin <ol...@gmail.com>]

Well put Howard!

I've bookmarked this post in the case I meet a PHB...

Olle


2009/6/17 Howard <hl...@gmail.com>

> I recently had an e-mail exchange with a Tapestry user; after
> congratulating me on creating Tapestry, he went on with the following
> observation on his organization: The company I work at unfortunately
> chose JSF for their big app. The reason was that Tapestry was "brittle"
> in the sense that, if one developer breaks something, on a page or a
> service, very often the whole site won't come up because the initial
> registry startup will fail. Or for example, if page A has a pagelink to
> page B, and page B is broken, then page A won't render. While I agree
> that we shouldn't ship unless the whole app is working, this is a
> thousands of pages big app with hundreds of mediocre (as in likely to
> break things) developers. They'd rather have 80% of the thing working
> than nothing at all. I never thought of this for my own projects, and
> haven't had the time to examine the truth of their claims. What's your
> take?
> I provided the following response:
> Early failures are absolutely, 100%, the only path towards code
> quality. You may have heard the phrase "no broken windows" (see "The
> Tipping Point" by Malcom Gladwell for more details) but the short form
> is that when errors go uncorrected (whether they are broken windows in
> an abandoned building, or broken code in an application) they tend to
> multiply quite rapidly.
> The things that will "break" a link from page A to page B are
> substantial problems such as invalid templates, references to unknown
> properties or components, or compile errors in the page B class ...
> things that no other developer should ever see when page B's developer
> is working and checking in code. That is, problems that should never be
> checked into trunk, but instead kept in a local workspace or a private
> branch.
> An organization that thinks that fail early is a problem is an
> organization that isn't prepared to develop a large application in any
> technology. The image I'm getting is one where there is no build
> server, no continuous integration, at best CVS for source code
> management (or possibly one of those "shared directory"
> monstrosities) .... i.e., a chaotic environment where errors are
> allowed to be checked in to the trunk and can go unnoticed for some
> time.
> The solution to coding errors in pages or components is not to wait
> until your testers (or end users) find the bugs, but to identify and
> fix the bugs early. That's called "engineering discipline" and the
> reality is that even self-professed "mediocre" developers can do it.
> Tapestry helps because it fails early and has great exception reporting
> to guide you right the problem so that you can fix it.
> Another factor here is enforced helplessness. If only Fred understands
> page B and he's out when it's broken, then all development stops
> waiting for Fred to get back. I hit this problem myself, years ago
> working on a large Struts application (those words give me the heebie
> jeebies now!). We had lots of code, a fragile and slow build process,
> and many little code "fiefdoms". I spent too much wasted time twiddling
> my thumbs.
> Nobody should "own the code"; if page B is is broken, Julie (who
> normally develops page A) should be free to fix it. Julie will need to
> understand the page B code well enough to fix it, but also you need an
> overall environment with shared source, no repository locks (that is,
> nothing that says "Only Fred can change this file"), and no management
> PHB's getting in the way. Pair programming is the best way for Fred and
> Julie to share knowledge so that they can understand each other's code.
> Even if pairing occurs only part time, it's very effective at knowledge
> transfer as well as ordinary coding.
> The idea that "mediocre" developers should use JSF as it is more
> tolerant of errors is absurd! Tapestry 5 is designed to improve
> productivity for all developers, by streamlining, simplifying, being
> smart and being concise ... not to mention live class reloading and
> best-of-breed exception reporting, which makes it fast to identify and
> fix those errors.
> If your doctor tells you to eat less red meat, that doesn't mean you
> should switch to a diet of fried chicken three meals a day! Likewise,
> if you have concerns with code quality from your developers, you should
> not switch to a less agile, more code-intensive, less supportive
> development model and hope to catch all the bugs in QA. Sweeping
> problems under the rug is never a winning strategy.
> Coming down off my soap box, I should also add that Tapestry 5.1 works
> a little bit differently than 5.0 in this respect, so it does (in fact)
> defer more of the page loading and validation until a link is actually
> clicked. This is more for performance reasons than to shield developers
> from application problems. Even in 5.0, the loading and validation was
> the "reach" from page A to pages explicitly referenced (usually via
> PageLink during the rendering of page A), so it's a highly unlikely
> case that a single error in a 1000 page application will keep the
> application from starting up, unless the start page of the application
> links to all 999 other pages.
> Re-reading the above post I can't emphasize enough: you can't ignore
> quality problems. Quality problems lead to development failures,
> schedule slips, missing functionality, low morale and high turnover.
> Saying "we don't have time to fix the quality problem first" is to
> ignore the the second law of Thermodynamics. You are expecting a
> miracle, literally writing it into your project plan.
> Formos addresses this issue two ways: First, we use Scrum and deliver
> on (typically) 4 week cycles. Thus we set real deadlines and have a
> constant check on quality (we're providing working code constantly). We
> don't even try to predict what we'll be doing six months or two years
> from now, we just deliver a steady, manageable stream of software.
> Secondly, Formos uses Tapestry because of all the reasons that the
> anonymous developer's organization rejected it, and for many, many more
> reasons besides.
>
> --
> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM




-- 
Olle Hallin
Senior Java Developer and Architect
olle.hallin@crisp.se
www.crisp.se

Re: [Tapestry Central] Why chose Tapestry?

[Peter Stavrinides <P....@albourne.com>]

Great post Howard, can't agree more! having an application keep running when its inherently broken is indeed absurd... reminds me of a car I owned once where some of the parts (bolts off the engine etc.) kept falling out while I was driving... needless to say I am still here today because I kept fixing it every time before driving it again! Taking into account the eternal problems of varying programmer skill, as well as the 'human factor', a modular, testable, robust, and fail fast framework such as Tapestry is great win. 

Peter


----- Original Message -----
From: "Igor Drobiazko" <ig...@gmail.com>
To: "Tapestry users" <us...@tapestry.apache.org>
Sent: Wednesday, 17 June, 2009 10:35:55 GMT +02:00 Athens, Beirut, Bucharest, Istanbul
Subject: Re: [Tapestry Central] Why chose Tapestry?

In the last years I battled for using Tapestry over JSF. There were a lot of
reasons why a lost the battle too often.
Most of them were non-technical but political. But this one is really
strange. It is not a question of a framework, it is a question of how you
develop you apps. As Howard already pointed out, they should write tests.
Companies, which do not write tests, suck.

Just image the same developer, who broke the page B a of a Tapestry app,
corrupts the central faces-config.xml of a JSF app.
Let's say he changes the scope of a managed bean from session  to request.
In this case the whole app is not working.

Another scenario is rafactoring: image you moved a component to a new
package but forgot to change the package in the faces-config.xml. In this
case there are more pages not working.

I would say you have much more places in a JSF app to make the app not
startable.

On Wed, Jun 17, 2009 at 1:20 AM, Howard <hl...@gmail.com> wrote:

> I recently had an e-mail exchange with a Tapestry user; after
> congratulating me on creating Tapestry, he went on with the following
> observation on his organization: The company I work at unfortunately
> chose JSF for their big app. The reason was that Tapestry was "brittle"
> in the sense that, if one developer breaks something, on a page or a
> service, very often the whole site won't come up because the initial
> registry startup will fail. Or for example, if page A has a pagelink to
> page B, and page B is broken, then page A won't render. While I agree
> that we shouldn't ship unless the whole app is working, this is a
> thousands of pages big app with hundreds of mediocre (as in likely to
> break things) developers. They'd rather have 80% of the thing working
> than nothing at all. I never thought of this for my own projects, and
> haven't had the time to examine the truth of their claims. What's your
> take?
> I provided the following response:
> Early failures are absolutely, 100%, the only path towards code
> quality. You may have heard the phrase "no broken windows" (see "The
> Tipping Point" by Malcom Gladwell for more details) but the short form
> is that when errors go uncorrected (whether they are broken windows in
> an abandoned building, or broken code in an application) they tend to
> multiply quite rapidly.
> The things that will "break" a link from page A to page B are
> substantial problems such as invalid templates, references to unknown
> properties or components, or compile errors in the page B class ...
> things that no other developer should ever see when page B's developer
> is working and checking in code. That is, problems that should never be
> checked into trunk, but instead kept in a local workspace or a private
> branch.
> An organization that thinks that fail early is a problem is an
> organization that isn't prepared to develop a large application in any
> technology. The image I'm getting is one where there is no build
> server, no continuous integration, at best CVS for source code
> management (or possibly one of those "shared directory"
> monstrosities) .... i.e., a chaotic environment where errors are
> allowed to be checked in to the trunk and can go unnoticed for some
> time.
> The solution to coding errors in pages or components is not to wait
> until your testers (or end users) find the bugs, but to identify and
> fix the bugs early. That's called "engineering discipline" and the
> reality is that even self-professed "mediocre" developers can do it.
> Tapestry helps because it fails early and has great exception reporting
> to guide you right the problem so that you can fix it.
> Another factor here is enforced helplessness. If only Fred understands
> page B and he's out when it's broken, then all development stops
> waiting for Fred to get back. I hit this problem myself, years ago
> working on a large Struts application (those words give me the heebie
> jeebies now!). We had lots of code, a fragile and slow build process,
> and many little code "fiefdoms". I spent too much wasted time twiddling
> my thumbs.
> Nobody should "own the code"; if page B is is broken, Julie (who
> normally develops page A) should be free to fix it. Julie will need to
> understand the page B code well enough to fix it, but also you need an
> overall environment with shared source, no repository locks (that is,
> nothing that says "Only Fred can change this file"), and no management
> PHB's getting in the way. Pair programming is the best way for Fred and
> Julie to share knowledge so that they can understand each other's code.
> Even if pairing occurs only part time, it's very effective at knowledge
> transfer as well as ordinary coding.
> The idea that "mediocre" developers should use JSF as it is more
> tolerant of errors is absurd! Tapestry 5 is designed to improve
> productivity for all developers, by streamlining, simplifying, being
> smart and being concise ... not to mention live class reloading and
> best-of-breed exception reporting, which makes it fast to identify and
> fix those errors.
> If your doctor tells you to eat less red meat, that doesn't mean you
> should switch to a diet of fried chicken three meals a day! Likewise,
> if you have concerns with code quality from your developers, you should
> not switch to a less agile, more code-intensive, less supportive
> development model and hope to catch all the bugs in QA. Sweeping
> problems under the rug is never a winning strategy.
> Coming down off my soap box, I should also add that Tapestry 5.1 works
> a little bit differently than 5.0 in this respect, so it does (in fact)
> defer more of the page loading and validation until a link is actually
> clicked. This is more for performance reasons than to shield developers
> from application problems. Even in 5.0, the loading and validation was
> the "reach" from page A to pages explicitly referenced (usually via
> PageLink during the rendering of page A), so it's a highly unlikely
> case that a single error in a 1000 page application will keep the
> application from starting up, unless the start page of the application
> links to all 999 other pages.
> Re-reading the above post I can't emphasize enough: you can't ignore
> quality problems. Quality problems lead to development failures,
> schedule slips, missing functionality, low morale and high turnover.
> Saying "we don't have time to fix the quality problem first" is to
> ignore the the second law of Thermodynamics. You are expecting a
> miracle, literally writing it into your project plan.
> Formos addresses this issue two ways: First, we use Scrum and deliver
> on (typically) 4 week cycles. Thus we set real deadlines and have a
> constant check on quality (we're providing working code constantly). We
> don't even try to predict what we'll be doing six months or two years
> from now, we just deliver a steady, manageable stream of software.
> Secondly, Formos uses Tapestry because of all the reasons that the
> anonymous developer's organization rejected it, and for many, many more
> reasons besides.
>
> --
> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM




-- 
Best regards,

Igor Drobiazko

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Igor Drobiazko <ig...@gmail.com>]

In the last years I battled for using Tapestry over JSF. There were a lot of
reasons why a lost the battle too often.
Most of them were non-technical but political. But this one is really
strange. It is not a question of a framework, it is a question of how you
develop you apps. As Howard already pointed out, they should write tests.
Companies, which do not write tests, suck.

Just image the same developer, who broke the page B a of a Tapestry app,
corrupts the central faces-config.xml of a JSF app.
Let's say he changes the scope of a managed bean from session  to request.
In this case the whole app is not working.

Another scenario is rafactoring: image you moved a component to a new
package but forgot to change the package in the faces-config.xml. In this
case there are more pages not working.

I would say you have much more places in a JSF app to make the app not
startable.

On Wed, Jun 17, 2009 at 1:20 AM, Howard <hl...@gmail.com> wrote:

> I recently had an e-mail exchange with a Tapestry user; after
> congratulating me on creating Tapestry, he went on with the following
> observation on his organization: The company I work at unfortunately
> chose JSF for their big app. The reason was that Tapestry was "brittle"
> in the sense that, if one developer breaks something, on a page or a
> service, very often the whole site won't come up because the initial
> registry startup will fail. Or for example, if page A has a pagelink to
> page B, and page B is broken, then page A won't render. While I agree
> that we shouldn't ship unless the whole app is working, this is a
> thousands of pages big app with hundreds of mediocre (as in likely to
> break things) developers. They'd rather have 80% of the thing working
> than nothing at all. I never thought of this for my own projects, and
> haven't had the time to examine the truth of their claims. What's your
> take?
> I provided the following response:
> Early failures are absolutely, 100%, the only path towards code
> quality. You may have heard the phrase "no broken windows" (see "The
> Tipping Point" by Malcom Gladwell for more details) but the short form
> is that when errors go uncorrected (whether they are broken windows in
> an abandoned building, or broken code in an application) they tend to
> multiply quite rapidly.
> The things that will "break" a link from page A to page B are
> substantial problems such as invalid templates, references to unknown
> properties or components, or compile errors in the page B class ...
> things that no other developer should ever see when page B's developer
> is working and checking in code. That is, problems that should never be
> checked into trunk, but instead kept in a local workspace or a private
> branch.
> An organization that thinks that fail early is a problem is an
> organization that isn't prepared to develop a large application in any
> technology. The image I'm getting is one where there is no build
> server, no continuous integration, at best CVS for source code
> management (or possibly one of those "shared directory"
> monstrosities) .... i.e., a chaotic environment where errors are
> allowed to be checked in to the trunk and can go unnoticed for some
> time.
> The solution to coding errors in pages or components is not to wait
> until your testers (or end users) find the bugs, but to identify and
> fix the bugs early. That's called "engineering discipline" and the
> reality is that even self-professed "mediocre" developers can do it.
> Tapestry helps because it fails early and has great exception reporting
> to guide you right the problem so that you can fix it.
> Another factor here is enforced helplessness. If only Fred understands
> page B and he's out when it's broken, then all development stops
> waiting for Fred to get back. I hit this problem myself, years ago
> working on a large Struts application (those words give me the heebie
> jeebies now!). We had lots of code, a fragile and slow build process,
> and many little code "fiefdoms". I spent too much wasted time twiddling
> my thumbs.
> Nobody should "own the code"; if page B is is broken, Julie (who
> normally develops page A) should be free to fix it. Julie will need to
> understand the page B code well enough to fix it, but also you need an
> overall environment with shared source, no repository locks (that is,
> nothing that says "Only Fred can change this file"), and no management
> PHB's getting in the way. Pair programming is the best way for Fred and
> Julie to share knowledge so that they can understand each other's code.
> Even if pairing occurs only part time, it's very effective at knowledge
> transfer as well as ordinary coding.
> The idea that "mediocre" developers should use JSF as it is more
> tolerant of errors is absurd! Tapestry 5 is designed to improve
> productivity for all developers, by streamlining, simplifying, being
> smart and being concise ... not to mention live class reloading and
> best-of-breed exception reporting, which makes it fast to identify and
> fix those errors.
> If your doctor tells you to eat less red meat, that doesn't mean you
> should switch to a diet of fried chicken three meals a day! Likewise,
> if you have concerns with code quality from your developers, you should
> not switch to a less agile, more code-intensive, less supportive
> development model and hope to catch all the bugs in QA. Sweeping
> problems under the rug is never a winning strategy.
> Coming down off my soap box, I should also add that Tapestry 5.1 works
> a little bit differently than 5.0 in this respect, so it does (in fact)
> defer more of the page loading and validation until a link is actually
> clicked. This is more for performance reasons than to shield developers
> from application problems. Even in 5.0, the loading and validation was
> the "reach" from page A to pages explicitly referenced (usually via
> PageLink during the rendering of page A), so it's a highly unlikely
> case that a single error in a 1000 page application will keep the
> application from starting up, unless the start page of the application
> links to all 999 other pages.
> Re-reading the above post I can't emphasize enough: you can't ignore
> quality problems. Quality problems lead to development failures,
> schedule slips, missing functionality, low morale and high turnover.
> Saying "we don't have time to fix the quality problem first" is to
> ignore the the second law of Thermodynamics. You are expecting a
> miracle, literally writing it into your project plan.
> Formos addresses this issue two ways: First, we use Scrum and deliver
> on (typically) 4 week cycles. Thus we set real deadlines and have a
> constant check on quality (we're providing working code constantly). We
> don't even try to predict what we'll be doing six months or two years
> from now, we just deliver a steady, manageable stream of software.
> Secondly, Formos uses Tapestry because of all the reasons that the
> anonymous developer's organization rejected it, and for many, many more
> reasons besides.
>
> --
> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM




-- 
Best regards,

Igor Drobiazko

Re: [Tapestry Central] Why chose Tapestry?

[Ville Virtanen <vi...@cerion.fi>]

Don't know if I double posted but..

Indeed, if you aim to code shit, please don't use T5 :)

The best case scenario would be that the compiler would detect all errors. 
The next best case would be that the app would point out what is wrong when
it starts.
The worst case is to have to click through the thousands of pages to even
detect that you can access it.

 - Ville 


Howard Lewis Ship wrote:
> 
> I recently had an e-mail exchange with a Tapestry user; after
> congratulating me on creating Tapestry, he went on with the following
> observation on his organization: The company I work at unfortunately
> chose JSF for their big app. The reason was that Tapestry was "brittle"
> in the sense that, if one developer breaks something, on a page or a
> service, very often the whole site won't come up because the initial
> registry startup will fail. Or for example, if page A has a pagelink to
> page B, and page B is broken, then page A won't render. While I agree
> that we shouldn't ship unless the whole app is working, this is a
> thousands of pages big app with hundreds of mediocre (as in likely to
> break things) developers. They'd rather have 80% of the thing working
> than nothing at all. I never thought of this for my own projects, and
> haven't had the time to examine the truth of their claims. What's your
> take?
> I provided the following response:
> Early failures are absolutely, 100%, the only path towards code
> quality. You may have heard the phrase "no broken windows" (see "The
> Tipping Point" by Malcom Gladwell for more details) but the short form
> is that when errors go uncorrected (whether they are broken windows in
> an abandoned building, or broken code in an application) they tend to
> multiply quite rapidly.
> The things that will "break" a link from page A to page B are
> substantial problems such as invalid templates, references to unknown
> properties or components, or compile errors in the page B class ...
> things that no other developer should ever see when page B's developer
> is working and checking in code. That is, problems that should never be
> checked into trunk, but instead kept in a local workspace or a private
> branch.
> An organization that thinks that fail early is a problem is an
> organization that isn't prepared to develop a large application in any
> technology. The image I'm getting is one where there is no build
> server, no continuous integration, at best CVS for source code
> management (or possibly one of those "shared directory"
> monstrosities) .... i.e., a chaotic environment where errors are
> allowed to be checked in to the trunk and can go unnoticed for some
> time.
> The solution to coding errors in pages or components is not to wait
> until your testers (or end users) find the bugs, but to identify and
> fix the bugs early. That's called "engineering discipline" and the
> reality is that even self-professed "mediocre" developers can do it.
> Tapestry helps because it fails early and has great exception reporting
> to guide you right the problem so that you can fix it.
> Another factor here is enforced helplessness. If only Fred understands
> page B and he's out when it's broken, then all development stops
> waiting for Fred to get back. I hit this problem myself, years ago
> working on a large Struts application (those words give me the heebie
> jeebies now!). We had lots of code, a fragile and slow build process,
> and many little code "fiefdoms". I spent too much wasted time twiddling
> my thumbs.
> Nobody should "own the code"; if page B is is broken, Julie (who
> normally develops page A) should be free to fix it. Julie will need to
> understand the page B code well enough to fix it, but also you need an
> overall environment with shared source, no repository locks (that is,
> nothing that says "Only Fred can change this file"), and no management
> PHB's getting in the way. Pair programming is the best way for Fred and
> Julie to share knowledge so that they can understand each other's code.
> Even if pairing occurs only part time, it's very effective at knowledge
> transfer as well as ordinary coding.
> The idea that "mediocre" developers should use JSF as it is more
> tolerant of errors is absurd! Tapestry 5 is designed to improve
> productivity for all developers, by streamlining, simplifying, being
> smart and being concise ... not to mention live class reloading and
> best-of-breed exception reporting, which makes it fast to identify and
> fix those errors.
> If your doctor tells you to eat less red meat, that doesn't mean you
> should switch to a diet of fried chicken three meals a day! Likewise,
> if you have concerns with code quality from your developers, you should
> not switch to a less agile, more code-intensive, less supportive
> development model and hope to catch all the bugs in QA. Sweeping
> problems under the rug is never a winning strategy.
> Coming down off my soap box, I should also add that Tapestry 5.1 works
> a little bit differently than 5.0 in this respect, so it does (in fact)
> defer more of the page loading and validation until a link is actually
> clicked. This is more for performance reasons than to shield developers
> from application problems. Even in 5.0, the loading and validation was
> the "reach" from page A to pages explicitly referenced (usually via
> PageLink during the rendering of page A), so it's a highly unlikely
> case that a single error in a 1000 page application will keep the
> application from starting up, unless the start page of the application
> links to all 999 other pages.
> Re-reading the above post I can't emphasize enough: you can't ignore
> quality problems. Quality problems lead to development failures,
> schedule slips, missing functionality, low morale and high turnover.
> Saying "we don't have time to fix the quality problem first" is to
> ignore the the second law of Thermodynamics. You are expecting a
> miracle, literally writing it into your project plan.
> Formos addresses this issue two ways: First, we use Scrum and deliver
> on (typically) 4 week cycles. Thus we set real deadlines and have a
> constant check on quality (we're providing working code constantly). We
> don't even try to predict what we'll be doing six months or two years
> from now, we just deliver a steady, manageable stream of software.
> Secondly, Formos uses Tapestry because of all the reasons that the
> anonymous developer's organization rejected it, and for many, many more
> reasons besides.
> 
> --
> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> 

-- 
View this message in context: http://www.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp24064891p24067677.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Brandon Atkinson <br...@gmail.com>]

I second.  Maven usually works as advertised.

In fact, one of the reasons I considered Tapestry superior to some other web
frameworks is that it integrates with Maven, and tutorials provided
archetypes for a quick start.

Maven is far from perfect, but it is the best out there if you use
continuous integration and such.


On Wed, Jun 17, 2009 at 2:31 PM, Geoffrey Wiseman <
geoffrey.wiseman@gmail.com> wrote:

> On Wed, Jun 17, 2009 at 1:21 PM, Norman Franke <no...@myasd.com> wrote:
>
> > Chapter 2 just plain didn't work for me. I think part of it is due to
> Maven
> > generally being extremely fragile and working less than half of the time.
> > However, even after working around that, you can't just import the
> project
> > into Eclipse. At least not under Eclipse 3.4.2.
> >
>
> Weird.  Maven has a lot of issues, IMO, but working less than half the time
> doesn't tend to be one of them for me.  And certainly the project generated
> by eclipse:eclipse imports fine into Eclipse 3.4.2 for me, which I've done
> in countless projects, including a few with Tapestry.  Maybe if we had
> specifics here we could help to diagnose.
>
>  - Geoffrey
> --
> Geoffrey Wiseman
> http://www.geoffreywiseman.ca/
>

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

On Jun 17, 2009, at 6:19 PM, Thiago H. de Paula Figueiredo wrote:

> Em Wed, 17 Jun 2009 18:29:05 -0300, Norman Franke <no...@myasd.com>  
> escreveu:
>
>> Once you get it working for a project, it generally works. It's the  
>> starting of new projects where problems arise. I've had to purge  
>> my .m2 directly countless times. Just yesterday, while adding  
>> tapestry5-acegi support, Maven decided to use Tapestry 5.1.0.5 with  
>> Tapestry Annotations 5.0.x, leading to all sorts of problems.
>
> Tapestry-Acegi was abondoned some time ago in favor of Tapestry- 
> Spring-Security. Thus, I guess Tapestry-Acegi has a explicit  
> dependency in tapestry-core or tapestry5-annotations 5.0.18, causing  
> the version mismatch.
>
>> From googling, it seems a major problem with Maven is that your  
>> build environment is now dependent on rules on potentially dozens  
>> of other sites.
>
> IMHO, it's an exageration. It all dependends on the repositores you  
> use. They are the central one and the ones included by used  
> projects' pom.xml files. A build would be more irreproducible if  
> repositories had duplicate projects inside them, but besides the  
> central and the Ibiblio one, repositories tend to have only their  
> own projects.
>
>> This makes reproducibility nearly impossible. One slight typo and  
>> no one can build.
>
> I don't see how one typo in some repository would lead to a  
> situation where no one can build.

Screw up a dependency or something. I keep reading about it via google  
searches, so it's not that uncommon.

>> I think this is a major hit to developer productivity. Sort of,  
>> "gee, it worked last week and I didn't touch anything."
>
> I use Maven for years and this kind of problem you mention only  
> happened a couple times, all them with Maven plugins, not project  
> dependencies. They were solved by just specifiying an explicit  
> version. Anyway, recent Maven development is addressing these issues.

That's good, but not really by main complaint. It was that getting  
started with T5 development was further complicated by Maven, at least  
in my case. Removing my .m2 directory solved some problems and I do  
hope they fix it. But regardless of that, getting started with  
Tapestry 5.1 needs to be more obvious.

I'm at least glad to hear that it does work well for people, since  
that's what I have working at present. :)

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com

Re: [Tapestry Central] Why chose Tapestry?

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

Em Wed, 17 Jun 2009 18:29:05 -0300, Norman Franke <no...@myasd.com>  
escreveu:

> Once you get it working for a project, it generally works. It's the  
> starting of new projects where problems arise. I've had to purge my .m2  
> directly countless times. Just yesterday, while adding tapestry5-acegi  
> support, Maven decided to use Tapestry 5.1.0.5 with Tapestry Annotations  
> 5.0.x, leading to all sorts of problems.

Tapestry-Acegi was abondoned some time ago in favor of  
Tapestry-Spring-Security. Thus, I guess Tapestry-Acegi has a explicit  
dependency in tapestry-core or tapestry5-annotations 5.0.18, causing the  
version mismatch.

> From googling, it seems a major problem with Maven is that your build  
> environment is now dependent on rules on potentially dozens of other  
> sites.

IMHO, it's an exageration. It all dependends on the repositores you use.  
They are the central one and the ones included by used projects' pom.xml  
files. A build would be more irreproducible if repositories had duplicate  
projects inside them, but besides the central and the Ibiblio one,  
repositories tend to have only their own projects.

> This makes reproducibility nearly impossible. One slight typo and no one  
> can build.

I don't see how one typo in some repository would lead to a situation  
where no one can build.

> I think this is a major hit to developer productivity. Sort of, "gee, it  
> worked last week and I didn't touch anything."

I use Maven for years and this kind of problem you mention only happened a  
couple times, all them with Maven plugins, not project dependencies. They  
were solved by just specifiying an explicit version. Anyway, recent Maven  
development is addressing these issues.

-- 
Thiago H. de Paula Figueiredo
Independent Java consultant, developer, and instructor
http://www.arsmachina.com.br/thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

On Jun 17, 2009, at 2:31 PM, Geoffrey Wiseman wrote:

> On Wed, Jun 17, 2009 at 1:21 PM, Norman Franke <no...@myasd.com>  
> wrote:
>
>> Chapter 2 just plain didn't work for me. I think part of it is due  
>> to Maven
>> generally being extremely fragile and working less than half of the  
>> time.
>> However, even after working around that, you can't just import the  
>> project
>> into Eclipse. At least not under Eclipse 3.4.2.
>>
>
> Weird.  Maven has a lot of issues, IMO, but working less than half  
> the time
> doesn't tend to be one of them for me.  And certainly the project  
> generated
> by eclipse:eclipse imports fine into Eclipse 3.4.2 for me, which  
> I've done
> in countless projects, including a few with Tapestry.  Maybe if we had
> specifics here we could help to diagnose.

Once you get it working for a project, it generally works. It's the  
starting of new projects where problems arise. I've had to purge  
my .m2 directly countless times. Just yesterday, while adding  
tapestry5-acegi support, Maven decided to use Tapestry 5.1.0.5 with  
Tapestry Annotations 5.0.x, leading to all sorts of problems. I had to  
move the dependancy for Tapestry 5 first in the pom.xml, and that  
fixed it. At least it works now.

While trying appfuse, I was never able to get Maven to build a  
project. Random errors about missing this or that. From googling, it  
seems a major problem with Maven is that your build environment is now  
dependent on rules on potentially dozens of other sites. This makes  
reproducibility nearly impossible. One slight typo and no one can  
build. I think this is a major hit to developer productivity. Sort of,  
"gee, it worked last week and I didn't touch anything." That's just  
not acceptable, IMHO. But, it's popular and mostly works, so I have no  
problems using it.

I don't think the tutorial said to run mvn eclipse:eclipse either,  
just import it into eclipse. That fails.

-Norman



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Geoffrey Wiseman <ge...@gmail.com>]

On Wed, Jun 17, 2009 at 1:21 PM, Norman Franke <no...@myasd.com> wrote:

> Chapter 2 just plain didn't work for me. I think part of it is due to Maven
> generally being extremely fragile and working less than half of the time.
> However, even after working around that, you can't just import the project
> into Eclipse. At least not under Eclipse 3.4.2.
>

Weird.  Maven has a lot of issues, IMO, but working less than half the time
doesn't tend to be one of them for me.  And certainly the project generated
by eclipse:eclipse imports fine into Eclipse 3.4.2 for me, which I've done
in countless projects, including a few with Tapestry.  Maybe if we had
specifics here we could help to diagnose.

  - Geoffrey
-- 
Geoffrey Wiseman
http://www.geoffreywiseman.ca/

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

And had I been able to find that, I'd have likely read it. That should  
either be in place of the so-outdated-it's-useless tutorial or at  
least have an easy to find link.

I think all the pieces are there, just hard to find. Not being a maven  
guru, I'd never even think to look under "tapestry 5 maven support" to  
get a project up and running.

In reading the main T5.1 page, there is no obvious way to get started.

Your link does appear helpful, just wish I'd have known. I likely  
won't give up, just hoping whoever has edit capabilities to the main  
tapestry page on apache.org can fix this. It wouldn't take more than  
like 30 minutes.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Jun 17, 2009, at 3:57 PM, Borut Bolčina wrote:

> Hello Norman
>
> 2009/6/17 Norman Franke <no...@myasd.com>
>
>> Back to Maven. After some googling, I found this article:
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) 
>> <http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+%28including+Maven%29 
>> > Shouldn't
>> this be included in the tutorial? Sadly, the tutorial is extremely  
>> basic,
>> but at least it works. (And is the only way I've found to actually  
>> create a
>> new project in Eclipse to date.)
>>
>> Yes, the documentation is poorly organized and too technical for  
>> beginners,
> that is why I decided to write some start-up material at
> http://bbwebcraft.blogspot.com/. I wish I had more time to continue  
> - my
> young daughter is a project on its own :-)
>
> Luckily Howard's plan is to write documentation, documentation and  
> some more
> documentation in the near future.
>
> Cheers,
> Borut
>
> P.S. Don't give up.

Re: [Tapestry Central] Why chose Tapestry?

[Borut Bolčina <bo...@gmail.com>]

Hello Norman

2009/6/17 Norman Franke <no...@myasd.com>

> Back to Maven. After some googling, I found this article:
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven)<http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+%28including+Maven%29> Shouldn't
> this be included in the tutorial? Sadly, the tutorial is extremely basic,
> but at least it works. (And is the only way I've found to actually create a
> new project in Eclipse to date.)
>
> Yes, the documentation is poorly organized and too technical for beginners,
that is why I decided to write some start-up material at
http://bbwebcraft.blogspot.com/. I wish I had more time to continue - my
young daughter is a project on its own :-)

Luckily Howard's plan is to write documentation, documentation and some more
documentation in the near future.

Cheers,
Borut

P.S. Don't give up.

Re: [Tapestry Central] Why chose Tapestry?

[Joel Halbert <jo...@su3analytics.com>]

Ivano - I use Eclipse 3.4 with the inbuilt server runtime environment - using 
tomcat & jetty. I don't use Maven, instead I just dropped the few tapestry 5 
jars i  needed into my projects. It should take no time at all to set up, and 
should work fine for you. 


On Thursday 18 June 2009 13:46:40 Ivano Luberti wrote:
> I'm a T4 user that is evaluating if to move to T5.
> If I well understand Norman message, it is not possible to develop with
> T5 using Eclipse3.4 with WTP like with T4?
>
> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
> versioning and ANT to generate deployments.
>
> To introduce Maven would be really time consuming and hence exepnsive.
>
> Norman Franke ha scritto:
> > I've been using T4/4.1 for several years and have been quite pleased
> > with it. I've been using it with Hibernate, and while not perfect,
> > it's worked pretty well. We've found it much faster to embed a web
> > browser in our main app and do editing, queries and the like via
> > Tapestry than writing native code.
> >
> > I have a new project to replace our aging billing system. I figured
> > this would be a great way to learn T5. So, I'm migrating me, not an
> > app. :-)
> >
> > I was pondering posting this, but this thread sort of pushed me over
> > the top. Note that I don't disagree with anything Howard said.
> > However, this almost became "Why I almost dumped Tapestry entirely."
> >
> > I'm writing this in order to solicit feedback and maybe help others.
> > I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
> > time time, and I'm very productive developing use them (and T4.1) I
> > think this is a pretty common development environment.
> >
> > To get started in T5 for a fresh new app, my first thought was to
> > follow the tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
> >
> > Chapter 2 just plain didn't work for me. I think part of it is due to
> > Maven generally being extremely fragile and working less than half of
> > the time. However, even after working around that, you can't just
> > import the project into Eclipse. At least not under Eclipse 3.4.2.
> >
> > No problem, I thought. Maven is annoying anyway. I'll just create a
> > Dynamic Web project (like I do for T4.1) and download the T5.1 binary
> > distribution. That's even worse. It comes with no README listing
> > dependencies or anything useful, and includes tons of libraries that
> > don't appear to be even needed. Tapestry failed to start up during
> > initialization. Why have a binary distro that doesn't work?
> >
> > Back to Maven. After some googling, I found this article:
> > http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven
> >) Shouldn't this be included in the tutorial? Sadly, the tutorial is
> > extremely basic, but at least it works. (And is the only way I've found
> > to actually create a new project in Eclipse to date.)
> >
> > Next, I tried Tapestry Jumpstart. After hours of configuration and
> > random errors (using Tomcat), it worked. However, it's so fragile and
> > klugy that I just can't see using it in production. I don't care about
> > OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
> > remote tomcat sessions eliminates many of the developer productivity
> > benefits of T5 in the first place. One thing I liked about T4 was that
> > I could deploy a WAR to a stock Tomcat install, and it would just
> > work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
> > just get a working developer environment, why even bother?
> >
> > Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
> > Sadly, AppFuse's T4 support is now broken due to a dependancy on
> > tapestry-flash that appears to be missing and following the
> > instructions on the AppFuse Tapestry 5 page doesn't work anymore
> > either, resulting in tons of missing resources.
> >
> > So, since T5 doesn't appear to provide much in the way of
> > authentication / security (a very basic requirement for almost all
> > webapps), I started down the tapestry5-acegi approach. Of course, that
> > doesn't work with T5.1. I managed to get it working and then upgraded
> > to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
> > augmentation. (Thanks to maven for not updating the packages when I
> > switched to the snapshot, too. I had to delete the "nu" directory in
> > my ~/.m2 directory. One more reason Maven blows. It just doesn't do
> > what you want.)
> >
> > I'd love to see more people use Tapestry, but after attempting a new
> > project, I'd feel embarrassed asking people to give Tapestry a look at
> > this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
> > go, despite all the benefits of T5. But, I really do want to start in
> > on T5 since I've loved using T4 for the last few years, and it does
> > seem to be a step forward.
> >
> > I think its common to want to just get something working in order to
> > get a feel for the framework. Doing so in Tapestry, at least for me,
> > has been a waste of two days. I finally, on the third day, I have
> > something that appears to allow the tutorial to work with basic
> > security. I'm not sure if others have similar problems and just gave
> > up without comment, making other frameworks seem more popular?
> >
> > Norman Franke
> > Answering Service for Directors, Inc.
> > www.myasd.com
> >
> > On Jun 16, 2009, at 7:20 PM, Howard wrote:
> >> I recently had an e-mail exchange with a Tapestry user; after
> >> congratulating me on creating Tapestry, he went on with the following
> >> observation on his organization: The company I work at unfortunately
> >> chose JSF for their big app. The reason was that Tapestry was "brittle"
> >> in the sense that, if one developer breaks something, on a page or a
> >> service, very often the whole site won't come up because the initial
> >> registry startup will fail. Or for example, if page A has a pagelink to
> >> page B, and page B is broken, then page A won't render. While I agree
> >> that we shouldn't ship unless the whole app is working, this is a
> >> thousands of pages big app with hundreds of mediocre (as in likely to
> >> break things) developers. They'd rather have 80% of the thing working
> >> than nothing at all. I never thought of this for my own projects, and
> >> haven't had the time to examine the truth of their claims. What's your
> >> take?
> >> I provided the following response:
> >> Early failures are absolutely, 100%, the only path towards code
> >> quality. You may have heard the phrase "no broken windows" (see "The
> >> Tipping Point" by Malcom Gladwell for more details) but the short form
> >> is that when errors go uncorrected (whether they are broken windows in
> >> an abandoned building, or broken code in an application) they tend to
> >> multiply quite rapidly.
> >> The things that will "break" a link from page A to page B are
> >> substantial problems such as invalid templates, references to unknown
> >> properties or components, or compile errors in the page B class ...
> >> things that no other developer should ever see when page B's developer
> >> is working and checking in code. That is, problems that should never be
> >> checked into trunk, but instead kept in a local workspace or a private
> >> branch.
> >> An organization that thinks that fail early is a problem is an
> >> organization that isn't prepared to develop a large application in any
> >> technology. The image I'm getting is one where there is no build
> >> server, no continuous integration, at best CVS for source code
> >> management (or possibly one of those "shared directory"
> >> monstrosities) .... i.e., a chaotic environment where errors are
> >> allowed to be checked in to the trunk and can go unnoticed for some
> >> time.
> >> The solution to coding errors in pages or components is not to wait
> >> until your testers (or end users) find the bugs, but to identify and
> >> fix the bugs early. That's called "engineering discipline" and the
> >> reality is that even self-professed "mediocre" developers can do it.
> >> Tapestry helps because it fails early and has great exception reporting
> >> to guide you right the problem so that you can fix it.
> >> Another factor here is enforced helplessness. If only Fred understands
> >> page B and he's out when it's broken, then all development stops
> >> waiting for Fred to get back. I hit this problem myself, years ago
> >> working on a large Struts application (those words give me the heebie
> >> jeebies now!). We had lots of code, a fragile and slow build process,
> >> and many little code "fiefdoms". I spent too much wasted time twiddling
> >> my thumbs.
> >> Nobody should "own the code"; if page B is is broken, Julie (who
> >> normally develops page A) should be free to fix it. Julie will need to
> >> understand the page B code well enough to fix it, but also you need an
> >> overall environment with shared source, no repository locks (that is,
> >> nothing that says "Only Fred can change this file"), and no management
> >> PHB's getting in the way. Pair programming is the best way for Fred and
> >> Julie to share knowledge so that they can understand each other's code.
> >> Even if pairing occurs only part time, it's very effective at knowledge
> >> transfer as well as ordinary coding.
> >> The idea that "mediocre" developers should use JSF as it is more
> >> tolerant of errors is absurd! Tapestry 5 is designed to improve
> >> productivity for all developers, by streamlining, simplifying, being
> >> smart and being concise ... not to mention live class reloading and
> >> best-of-breed exception reporting, which makes it fast to identify and
> >> fix those errors.
> >> If your doctor tells you to eat less red meat, that doesn't mean you
> >> should switch to a diet of fried chicken three meals a day! Likewise,
> >> if you have concerns with code quality from your developers, you should
> >> not switch to a less agile, more code-intensive, less supportive
> >> development model and hope to catch all the bugs in QA. Sweeping
> >> problems under the rug is never a winning strategy.
> >> Coming down off my soap box, I should also add that Tapestry 5.1 works
> >> a little bit differently than 5.0 in this respect, so it does (in fact)
> >> defer more of the page loading and validation until a link is actually
> >> clicked. This is more for performance reasons than to shield developers
> >> from application problems. Even in 5.0, the loading and validation was
> >> the "reach" from page A to pages explicitly referenced (usually via
> >> PageLink during the rendering of page A), so it's a highly unlikely
> >> case that a single error in a 1000 page application will keep the
> >> application from starting up, unless the start page of the application
> >> links to all 999 other pages.
> >> Re-reading the above post I can't emphasize enough: you can't ignore
> >> quality problems. Quality problems lead to development failures,
> >> schedule slips, missing functionality, low morale and high turnover.
> >> Saying "we don't have time to fix the quality problem first" is to
> >> ignore the the second law of Thermodynamics. You are expecting a
> >> miracle, literally writing it into your project plan.
> >> Formos addresses this issue two ways: First, we use Scrum and deliver
> >> on (typically) 4 week cycles. Thus we set real deadlines and have a
> >> constant check on quality (we're providing working code constantly). We
> >> don't even try to predict what we'll be doing six months or two years
> >> from now, we just deliver a steady, manageable stream of software.
> >> Secondly, Formos uses Tapestry because of all the reasons that the
> >> anonymous developer's organization rejected it, and for many, many more
> >> reasons besides.
> >>
> >> --
> >> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM



-- 
Joel Halbert
020 3051 8637
075 2501 0825
joel@su3analytics.com
www.su3analytics.com
www.storequery.com
SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Ivano Luberti <lu...@archicoop.it>]

Thanks all, now I have a more complete picture.
This list is wonderful !

Blower, Andy ha scritto:
> Well we develop T5 in Eclipse as a Dynamic Web Project using ANT and IVY for builds and dependencies. (+SVN for version control) There was a fair amount of work to set it up along with the CI server etc, but it works pretty well for us and everything was new to us. Anyway it is definitely possible.
>
> We considered Maven briefly, but a combination of nightmare stories (2 on Howard's blog itself), completely confusing documentation, Howard's intent to move T5 away from Maven (what happened to that plan over the last year or so?) and impending deadline for project start meant that we dumped Maven for a simpler system.
>
> Was that the correct decision? I don't know - Ivy took a while to figure out but generally does what it's told and only that and the rest is done using Ant scripts. It may have been a bit more work, but at least we understand how it works inside out. We do have to get dependencies from public Maven repositories (which can be problematic) - we only do this once and put it into a company-wide shared Ivy repository.
>
> Seems like Maven is a bit like Marmite... ;-)
>
>   
>> -----Original Message-----
>> From: Ivano Luberti [mailto:luberti@archicoop.it]
>> Sent: 18 June 2009 13:47
>> To: Tapestry users
>> Subject: Re: [Tapestry Central] Why chose Tapestry?
>>
>> I'm a T4 user that is evaluating if to move to T5.
>> If I well understand Norman message, it is not possible to develop with
>> T5 using Eclipse3.4 with WTP like with T4?
>>
>> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
>> versioning and ANT to generate deployments.
>>
>> To introduce Maven would be really time consuming and hence exepnsive.
>>
>>
>>
>> Norman Franke ha scritto:
>>     
>>> I've been using T4/4.1 for several years and have been quite pleased
>>> with it. I've been using it with Hibernate, and while not perfect,
>>> it's worked pretty well. We've found it much faster to embed a web
>>> browser in our main app and do editing, queries and the like via
>>> Tapestry than writing native code.
>>>
>>> I have a new project to replace our aging billing system. I figured
>>> this would be a great way to learn T5. So, I'm migrating me, not an
>>> app. :-)
>>>
>>> I was pondering posting this, but this thread sort of pushed me over
>>> the top. Note that I don't disagree with anything Howard said.
>>> However, this almost became "Why I almost dumped Tapestry entirely."
>>>
>>> I'm writing this in order to solicit feedback and maybe help others.
>>> I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
>>> time time, and I'm very productive developing use them (and T4.1) I
>>> think this is a pretty common development environment.
>>>
>>> To get started in T5 for a fresh new app, my first thought was to
>>> follow the tutorial at
>>>       
>> http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>     
>>> Chapter 2 just plain didn't work for me. I think part of it is due to
>>> Maven generally being extremely fragile and working less than half of
>>> the time. However, even after working around that, you can't just
>>> import the project into Eclipse. At least not under Eclipse 3.4.2.
>>>
>>> No problem, I thought. Maven is annoying anyway. I'll just create a
>>> Dynamic Web project (like I do for T4.1) and download the T5.1 binary
>>> distribution. That's even worse. It comes with no README listing
>>> dependencies or anything useful, and includes tons of libraries that
>>> don't appear to be even needed. Tapestry failed to start up during
>>> initialization. Why have a binary distro that doesn't work?
>>>
>>> Back to Maven. After some googling, I found this article:
>>>
>>>       
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mav
>> en) Shouldn't
>>     
>>> this be included in the tutorial? Sadly, the tutorial is extremely
>>> basic, but at least it works. (And is the only way I've found to
>>> actually create a new project in Eclipse to date.)
>>>
>>> Next, I tried Tapestry Jumpstart. After hours of configuration and
>>> random errors (using Tomcat), it worked. However, it's so fragile and
>>> klugy that I just can't see using it in production. I don't care
>>>       
>> about
>>     
>>> OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
>>> remote tomcat sessions eliminates many of the developer productivity
>>> benefits of T5 in the first place. One thing I liked about T4 was
>>>       
>> that
>>     
>>> I could deploy a WAR to a stock Tomcat install, and it would just
>>> work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
>>> just get a working developer environment, why even bother?
>>>
>>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
>>> Sadly, AppFuse's T4 support is now broken due to a dependancy on
>>> tapestry-flash that appears to be missing and following the
>>> instructions on the AppFuse Tapestry 5 page doesn't work anymore
>>> either, resulting in tons of missing resources.
>>>
>>> So, since T5 doesn't appear to provide much in the way of
>>> authentication / security (a very basic requirement for almost all
>>> webapps), I started down the tapestry5-acegi approach. Of course,
>>>       
>> that
>>     
>>> doesn't work with T5.1. I managed to get it working and then upgraded
>>> to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
>>> augmentation. (Thanks to maven for not updating the packages when I
>>> switched to the snapshot, too. I had to delete the "nu" directory in
>>> my ~/.m2 directory. One more reason Maven blows. It just doesn't do
>>> what you want.)
>>>
>>> I'd love to see more people use Tapestry, but after attempting a new
>>> project, I'd feel embarrassed asking people to give Tapestry a look
>>>       
>> at
>>     
>>> this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
>>> go, despite all the benefits of T5. But, I really do want to start in
>>> on T5 since I've loved using T4 for the last few years, and it does
>>> seem to be a step forward.
>>>
>>> I think its common to want to just get something working in order to
>>> get a feel for the framework. Doing so in Tapestry, at least for me,
>>> has been a waste of two days. I finally, on the third day, I have
>>> something that appears to allow the tutorial to work with basic
>>> security. I'm not sure if others have similar problems and just gave
>>> up without comment, making other frameworks seem more popular?
>>>
>>> Norman Franke
>>> Answering Service for Directors, Inc.
>>> www.myasd.com
>>>
>>>
>>>
>>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>>
>>>       
>>>> I recently had an e-mail exchange with a Tapestry user; after
>>>> congratulating me on creating Tapestry, he went on with the
>>>>         
>> following
>>     
>>>> observation on his organization: The company I work at unfortunately
>>>> chose JSF for their big app. The reason was that Tapestry was
>>>>         
>> "brittle"
>>     
>>>> in the sense that, if one developer breaks something, on a page or a
>>>> service, very often the whole site won't come up because the initial
>>>> registry startup will fail. Or for example, if page A has a pagelink
>>>>         
>> to
>>     
>>>> page B, and page B is broken, then page A won't render. While I
>>>>         
>> agree
>>     
>>>> that we shouldn't ship unless the whole app is working, this is a
>>>> thousands of pages big app with hundreds of mediocre (as in likely
>>>>         
>> to
>>     
>>>> break things) developers. They'd rather have 80% of the thing
>>>>         
>> working
>>     
>>>> than nothing at all. I never thought of this for my own projects,
>>>>         
>> and
>>     
>>>> haven't had the time to examine the truth of their claims. What's
>>>>         
>> your
>>     
>>>> take?
>>>> I provided the following response:
>>>> Early failures are absolutely, 100%, the only path towards code
>>>> quality. You may have heard the phrase "no broken windows" (see "The
>>>> Tipping Point" by Malcom Gladwell for more details) but the short
>>>>         
>> form
>>     
>>>> is that when errors go uncorrected (whether they are broken windows
>>>>         
>> in
>>     
>>>> an abandoned building, or broken code in an application) they tend
>>>>         
>> to
>>     
>>>> multiply quite rapidly.
>>>> The things that will "break" a link from page A to page B are
>>>> substantial problems such as invalid templates, references to
>>>>         
>> unknown
>>     
>>>> properties or components, or compile errors in the page B class ...
>>>> things that no other developer should ever see when page B's
>>>>         
>> developer
>>     
>>>> is working and checking in code. That is, problems that should never
>>>>         
>> be
>>     
>>>> checked into trunk, but instead kept in a local workspace or a
>>>>         
>> private
>>     
>>>> branch.
>>>> An organization that thinks that fail early is a problem is an
>>>> organization that isn't prepared to develop a large application in
>>>>         
>> any
>>     
>>>> technology. The image I'm getting is one where there is no build
>>>> server, no continuous integration, at best CVS for source code
>>>> management (or possibly one of those "shared directory"
>>>> monstrosities) .... i.e., a chaotic environment where errors are
>>>> allowed to be checked in to the trunk and can go unnoticed for some
>>>> time.
>>>> The solution to coding errors in pages or components is not to wait
>>>> until your testers (or end users) find the bugs, but to identify and
>>>> fix the bugs early. That's called "engineering discipline" and the
>>>> reality is that even self-professed "mediocre" developers can do it.
>>>> Tapestry helps because it fails early and has great exception
>>>>         
>> reporting
>>     
>>>> to guide you right the problem so that you can fix it.
>>>> Another factor here is enforced helplessness. If only Fred
>>>>         
>> understands
>>     
>>>> page B and he's out when it's broken, then all development stops
>>>> waiting for Fred to get back. I hit this problem myself, years ago
>>>> working on a large Struts application (those words give me the
>>>>         
>> heebie
>>     
>>>> jeebies now!). We had lots of code, a fragile and slow build
>>>>         
>> process,
>>     
>>>> and many little code "fiefdoms". I spent too much wasted time
>>>>         
>> twiddling
>>     
>>>> my thumbs.
>>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>>> normally develops page A) should be free to fix it. Julie will need
>>>>         
>> to
>>     
>>>> understand the page B code well enough to fix it, but also you need
>>>>         
>> an
>>     
>>>> overall environment with shared source, no repository locks (that
>>>>         
>> is,
>>     
>>>> nothing that says "Only Fred can change this file"), and no
>>>>         
>> management
>>     
>>>> PHB's getting in the way. Pair programming is the best way for Fred
>>>>         
>> and
>>     
>>>> Julie to share knowledge so that they can understand each other's
>>>>         
>> code.
>>     
>>>> Even if pairing occurs only part time, it's very effective at
>>>>         
>> knowledge
>>     
>>>> transfer as well as ordinary coding.
>>>> The idea that "mediocre" developers should use JSF as it is more
>>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>>> productivity for all developers, by streamlining, simplifying, being
>>>> smart and being concise ... not to mention live class reloading and
>>>> best-of-breed exception reporting, which makes it fast to identify
>>>>         
>> and
>>     
>>>> fix those errors.
>>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>>> should switch to a diet of fried chicken three meals a day!
>>>>         
>> Likewise,
>>     
>>>> if you have concerns with code quality from your developers, you
>>>>         
>> should
>>     
>>>> not switch to a less agile, more code-intensive, less supportive
>>>> development model and hope to catch all the bugs in QA. Sweeping
>>>> problems under the rug is never a winning strategy.
>>>> Coming down off my soap box, I should also add that Tapestry 5.1
>>>>         
>> works
>>     
>>>> a little bit differently than 5.0 in this respect, so it does (in
>>>>         
>> fact)
>>     
>>>> defer more of the page loading and validation until a link is
>>>>         
>> actually
>>     
>>>> clicked. This is more for performance reasons than to shield
>>>>         
>> developers
>>     
>>>> from application problems. Even in 5.0, the loading and validation
>>>>         
>> was
>>     
>>>> the "reach" from page A to pages explicitly referenced (usually via
>>>> PageLink during the rendering of page A), so it's a highly unlikely
>>>> case that a single error in a 1000 page application will keep the
>>>> application from starting up, unless the start page of the
>>>>         
>> application
>>     
>>>> links to all 999 other pages.
>>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>>> quality problems. Quality problems lead to development failures,
>>>> schedule slips, missing functionality, low morale and high turnover.
>>>> Saying "we don't have time to fix the quality problem first" is to
>>>> ignore the the second law of Thermodynamics. You are expecting a
>>>> miracle, literally writing it into your project plan.
>>>> Formos addresses this issue two ways: First, we use Scrum and
>>>>         
>> deliver
>>     
>>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>>> constant check on quality (we're providing working code constantly).
>>>>         
>> We
>>     
>>>> don't even try to predict what we'll be doing six months or two
>>>>         
>> years
>>     
>>>> from now, we just deliver a steady, manageable stream of software.
>>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>>> anonymous developer's organization rejected it, and for many, many
>>>>         
>> more
>>     
>>>> reasons besides.
>>>>
>>>> --
>>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>>>         
>>>       
>> --
>> ==================================================
>> dott. Ivano Mario Luberti
>> Archimede Informatica societa' cooperativa a r. l.
>> Sede Operativa
>> Via Gereschi 36 - 56126- Pisa
>> tel.: +39-050- 580959
>> tel/fax: +39-050-9711344
>> web: www.archicoop.it
>> ==================================================
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>     
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>   

-- 
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Brandon Atkinson <br...@gmail.com>]

>
> Seems like Maven is a bit like Marmite... ;-)


Meaning you love it or hate it?

RE: [Tapestry Central] Why chose Tapestry?

["Blower, Andy" <An...@proquest.co.uk>]

Well we develop T5 in Eclipse as a Dynamic Web Project using ANT and IVY for builds and dependencies. (+SVN for version control) There was a fair amount of work to set it up along with the CI server etc, but it works pretty well for us and everything was new to us. Anyway it is definitely possible.

We considered Maven briefly, but a combination of nightmare stories (2 on Howard's blog itself), completely confusing documentation, Howard's intent to move T5 away from Maven (what happened to that plan over the last year or so?) and impending deadline for project start meant that we dumped Maven for a simpler system.

Was that the correct decision? I don't know - Ivy took a while to figure out but generally does what it's told and only that and the rest is done using Ant scripts. It may have been a bit more work, but at least we understand how it works inside out. We do have to get dependencies from public Maven repositories (which can be problematic) - we only do this once and put it into a company-wide shared Ivy repository.

Seems like Maven is a bit like Marmite... ;-)

> -----Original Message-----
> From: Ivano Luberti [mailto:luberti@archicoop.it]
> Sent: 18 June 2009 13:47
> To: Tapestry users
> Subject: Re: [Tapestry Central] Why chose Tapestry?
> 
> I'm a T4 user that is evaluating if to move to T5.
> If I well understand Norman message, it is not possible to develop with
> T5 using Eclipse3.4 with WTP like with T4?
> 
> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
> versioning and ANT to generate deployments.
> 
> To introduce Maven would be really time consuming and hence exepnsive.
> 
> 
> 
> Norman Franke ha scritto:
> > I've been using T4/4.1 for several years and have been quite pleased
> > with it. I've been using it with Hibernate, and while not perfect,
> > it's worked pretty well. We've found it much faster to embed a web
> > browser in our main app and do editing, queries and the like via
> > Tapestry than writing native code.
> >
> > I have a new project to replace our aging billing system. I figured
> > this would be a great way to learn T5. So, I'm migrating me, not an
> > app. :-)
> >
> > I was pondering posting this, but this thread sort of pushed me over
> > the top. Note that I don't disagree with anything Howard said.
> > However, this almost became "Why I almost dumped Tapestry entirely."
> >
> > I'm writing this in order to solicit feedback and maybe help others.
> > I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
> > time time, and I'm very productive developing use them (and T4.1) I
> > think this is a pretty common development environment.
> >
> > To get started in T5 for a fresh new app, my first thought was to
> > follow the tutorial at
> http://tapestry.apache.org/tapestry5.1/tutorial1/.
> >
> > Chapter 2 just plain didn't work for me. I think part of it is due to
> > Maven generally being extremely fragile and working less than half of
> > the time. However, even after working around that, you can't just
> > import the project into Eclipse. At least not under Eclipse 3.4.2.
> >
> > No problem, I thought. Maven is annoying anyway. I'll just create a
> > Dynamic Web project (like I do for T4.1) and download the T5.1 binary
> > distribution. That's even worse. It comes with no README listing
> > dependencies or anything useful, and includes tons of libraries that
> > don't appear to be even needed. Tapestry failed to start up during
> > initialization. Why have a binary distro that doesn't work?
> >
> > Back to Maven. After some googling, I found this article:
> >
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mav
> en) Shouldn't
> > this be included in the tutorial? Sadly, the tutorial is extremely
> > basic, but at least it works. (And is the only way I've found to
> > actually create a new project in Eclipse to date.)
> >
> > Next, I tried Tapestry Jumpstart. After hours of configuration and
> > random errors (using Tomcat), it worked. However, it's so fragile and
> > klugy that I just can't see using it in production. I don't care
> about
> > OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
> > remote tomcat sessions eliminates many of the developer productivity
> > benefits of T5 in the first place. One thing I liked about T4 was
> that
> > I could deploy a WAR to a stock Tomcat install, and it would just
> > work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
> > just get a working developer environment, why even bother?
> >
> > Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
> > Sadly, AppFuse's T4 support is now broken due to a dependancy on
> > tapestry-flash that appears to be missing and following the
> > instructions on the AppFuse Tapestry 5 page doesn't work anymore
> > either, resulting in tons of missing resources.
> >
> > So, since T5 doesn't appear to provide much in the way of
> > authentication / security (a very basic requirement for almost all
> > webapps), I started down the tapestry5-acegi approach. Of course,
> that
> > doesn't work with T5.1. I managed to get it working and then upgraded
> > to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
> > augmentation. (Thanks to maven for not updating the packages when I
> > switched to the snapshot, too. I had to delete the "nu" directory in
> > my ~/.m2 directory. One more reason Maven blows. It just doesn't do
> > what you want.)
> >
> > I'd love to see more people use Tapestry, but after attempting a new
> > project, I'd feel embarrassed asking people to give Tapestry a look
> at
> > this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
> > go, despite all the benefits of T5. But, I really do want to start in
> > on T5 since I've loved using T4 for the last few years, and it does
> > seem to be a step forward.
> >
> > I think its common to want to just get something working in order to
> > get a feel for the framework. Doing so in Tapestry, at least for me,
> > has been a waste of two days. I finally, on the third day, I have
> > something that appears to allow the tutorial to work with basic
> > security. I'm not sure if others have similar problems and just gave
> > up without comment, making other frameworks seem more popular?
> >
> > Norman Franke
> > Answering Service for Directors, Inc.
> > www.myasd.com
> >
> >
> >
> > On Jun 16, 2009, at 7:20 PM, Howard wrote:
> >
> >> I recently had an e-mail exchange with a Tapestry user; after
> >> congratulating me on creating Tapestry, he went on with the
> following
> >> observation on his organization: The company I work at unfortunately
> >> chose JSF for their big app. The reason was that Tapestry was
> "brittle"
> >> in the sense that, if one developer breaks something, on a page or a
> >> service, very often the whole site won't come up because the initial
> >> registry startup will fail. Or for example, if page A has a pagelink
> to
> >> page B, and page B is broken, then page A won't render. While I
> agree
> >> that we shouldn't ship unless the whole app is working, this is a
> >> thousands of pages big app with hundreds of mediocre (as in likely
> to
> >> break things) developers. They'd rather have 80% of the thing
> working
> >> than nothing at all. I never thought of this for my own projects,
> and
> >> haven't had the time to examine the truth of their claims. What's
> your
> >> take?
> >> I provided the following response:
> >> Early failures are absolutely, 100%, the only path towards code
> >> quality. You may have heard the phrase "no broken windows" (see "The
> >> Tipping Point" by Malcom Gladwell for more details) but the short
> form
> >> is that when errors go uncorrected (whether they are broken windows
> in
> >> an abandoned building, or broken code in an application) they tend
> to
> >> multiply quite rapidly.
> >> The things that will "break" a link from page A to page B are
> >> substantial problems such as invalid templates, references to
> unknown
> >> properties or components, or compile errors in the page B class ...
> >> things that no other developer should ever see when page B's
> developer
> >> is working and checking in code. That is, problems that should never
> be
> >> checked into trunk, but instead kept in a local workspace or a
> private
> >> branch.
> >> An organization that thinks that fail early is a problem is an
> >> organization that isn't prepared to develop a large application in
> any
> >> technology. The image I'm getting is one where there is no build
> >> server, no continuous integration, at best CVS for source code
> >> management (or possibly one of those "shared directory"
> >> monstrosities) .... i.e., a chaotic environment where errors are
> >> allowed to be checked in to the trunk and can go unnoticed for some
> >> time.
> >> The solution to coding errors in pages or components is not to wait
> >> until your testers (or end users) find the bugs, but to identify and
> >> fix the bugs early. That's called "engineering discipline" and the
> >> reality is that even self-professed "mediocre" developers can do it.
> >> Tapestry helps because it fails early and has great exception
> reporting
> >> to guide you right the problem so that you can fix it.
> >> Another factor here is enforced helplessness. If only Fred
> understands
> >> page B and he's out when it's broken, then all development stops
> >> waiting for Fred to get back. I hit this problem myself, years ago
> >> working on a large Struts application (those words give me the
> heebie
> >> jeebies now!). We had lots of code, a fragile and slow build
> process,
> >> and many little code "fiefdoms". I spent too much wasted time
> twiddling
> >> my thumbs.
> >> Nobody should "own the code"; if page B is is broken, Julie (who
> >> normally develops page A) should be free to fix it. Julie will need
> to
> >> understand the page B code well enough to fix it, but also you need
> an
> >> overall environment with shared source, no repository locks (that
> is,
> >> nothing that says "Only Fred can change this file"), and no
> management
> >> PHB's getting in the way. Pair programming is the best way for Fred
> and
> >> Julie to share knowledge so that they can understand each other's
> code.
> >> Even if pairing occurs only part time, it's very effective at
> knowledge
> >> transfer as well as ordinary coding.
> >> The idea that "mediocre" developers should use JSF as it is more
> >> tolerant of errors is absurd! Tapestry 5 is designed to improve
> >> productivity for all developers, by streamlining, simplifying, being
> >> smart and being concise ... not to mention live class reloading and
> >> best-of-breed exception reporting, which makes it fast to identify
> and
> >> fix those errors.
> >> If your doctor tells you to eat less red meat, that doesn't mean you
> >> should switch to a diet of fried chicken three meals a day!
> Likewise,
> >> if you have concerns with code quality from your developers, you
> should
> >> not switch to a less agile, more code-intensive, less supportive
> >> development model and hope to catch all the bugs in QA. Sweeping
> >> problems under the rug is never a winning strategy.
> >> Coming down off my soap box, I should also add that Tapestry 5.1
> works
> >> a little bit differently than 5.0 in this respect, so it does (in
> fact)
> >> defer more of the page loading and validation until a link is
> actually
> >> clicked. This is more for performance reasons than to shield
> developers
> >> from application problems. Even in 5.0, the loading and validation
> was
> >> the "reach" from page A to pages explicitly referenced (usually via
> >> PageLink during the rendering of page A), so it's a highly unlikely
> >> case that a single error in a 1000 page application will keep the
> >> application from starting up, unless the start page of the
> application
> >> links to all 999 other pages.
> >> Re-reading the above post I can't emphasize enough: you can't ignore
> >> quality problems. Quality problems lead to development failures,
> >> schedule slips, missing functionality, low morale and high turnover.
> >> Saying "we don't have time to fix the quality problem first" is to
> >> ignore the the second law of Thermodynamics. You are expecting a
> >> miracle, literally writing it into your project plan.
> >> Formos addresses this issue two ways: First, we use Scrum and
> deliver
> >> on (typically) 4 week cycles. Thus we set real deadlines and have a
> >> constant check on quality (we're providing working code constantly).
> We
> >> don't even try to predict what we'll be doing six months or two
> years
> >> from now, we just deliver a steady, manageable stream of software.
> >> Secondly, Formos uses Tapestry because of all the reasons that the
> >> anonymous developer's organization rejected it, and for many, many
> more
> >> reasons besides.
> >>
> >> --
> >> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> >
> >
> 
> --
> ==================================================
> dott. Ivano Mario Luberti
> Archimede Informatica societa' cooperativa a r. l.
> Sede Operativa
> Via Gereschi 36 - 56126- Pisa
> tel.: +39-050- 580959
> tel/fax: +39-050-9711344
> web: www.archicoop.it
> ==================================================
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 



---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

It does work, after some fiddling. On the wiki there were some good  
notes on getting control-space completion to work with Tapestry using  
the JSP editor. I was also quite used to working with WTP, but I did  
get it working. Follow this:

http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven)

Then: http://wiki.apache.org/tapestry/Tapestry5JSPEditorEclipse
(Which needs to be updated for the 5.1 XTD, btw.)

Now I can develop using WTP.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Jun 18, 2009, at 8:46 AM, Ivano Luberti wrote:

> I'm a T4 user that is evaluating if to move to T5.
> If I well understand Norman message, it is not possible to develop  
> with
> T5 using Eclipse3.4 with WTP like with T4?
>
> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
> versioning and ANT to generate deployments.
>
> To introduce Maven would be really time consuming and hence exepnsive.
>
>
>
> Norman Franke ha scritto:
>> I've been using T4/4.1 for several years and have been quite pleased
>> with it. I've been using it with Hibernate, and while not perfect,
>> it's worked pretty well. We've found it much faster to embed a web
>> browser in our main app and do editing, queries and the like via
>> Tapestry than writing native code.
>>
>> I have a new project to replace our aging billing system. I figured
>> this would be a great way to learn T5. So, I'm migrating me, not an
>> app. :-)
>>
>> I was pondering posting this, but this thread sort of pushed me over
>> the top. Note that I don't disagree with anything Howard said.
>> However, this almost became "Why I almost dumped Tapestry entirely."
>>
>> I'm writing this in order to solicit feedback and maybe help others.
>> I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
>> time time, and I'm very productive developing use them (and T4.1) I
>> think this is a pretty common development environment.
>>
>> To get started in T5 for a fresh new app, my first thought was to
>> follow the tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/ 
>> .
>>
>> Chapter 2 just plain didn't work for me. I think part of it is due to
>> Maven generally being extremely fragile and working less than half of
>> the time. However, even after working around that, you can't just
>> import the project into Eclipse. At least not under Eclipse 3.4.2.
>>
>> No problem, I thought. Maven is annoying anyway. I'll just create a
>> Dynamic Web project (like I do for T4.1) and download the T5.1 binary
>> distribution. That's even worse. It comes with no README listing
>> dependencies or anything useful, and includes tons of libraries that
>> don't appear to be even needed. Tapestry failed to start up during
>> initialization. Why have a binary distro that doesn't work?
>>
>> Back to Maven. After some googling, I found this article:
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) 
>>  Shouldn't
>> this be included in the tutorial? Sadly, the tutorial is extremely
>> basic, but at least it works. (And is the only way I've found to
>> actually create a new project in Eclipse to date.)
>>
>> Next, I tried Tapestry Jumpstart. After hours of configuration and
>> random errors (using Tomcat), it worked. However, it's so fragile and
>> klugy that I just can't see using it in production. I don't care  
>> about
>> OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
>> remote tomcat sessions eliminates many of the developer productivity
>> benefits of T5 in the first place. One thing I liked about T4 was  
>> that
>> I could deploy a WAR to a stock Tomcat install, and it would just
>> work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
>> just get a working developer environment, why even bother?
>>
>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
>> Sadly, AppFuse's T4 support is now broken due to a dependancy on
>> tapestry-flash that appears to be missing and following the
>> instructions on the AppFuse Tapestry 5 page doesn't work anymore
>> either, resulting in tons of missing resources.
>>
>> So, since T5 doesn't appear to provide much in the way of
>> authentication / security (a very basic requirement for almost all
>> webapps), I started down the tapestry5-acegi approach. Of course,  
>> that
>> doesn't work with T5.1. I managed to get it working and then upgraded
>> to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
>> augmentation. (Thanks to maven for not updating the packages when I
>> switched to the snapshot, too. I had to delete the "nu" directory in
>> my ~/.m2 directory. One more reason Maven blows. It just doesn't do
>> what you want.)
>>
>> I'd love to see more people use Tapestry, but after attempting a new
>> project, I'd feel embarrassed asking people to give Tapestry a look  
>> at
>> this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
>> go, despite all the benefits of T5. But, I really do want to start in
>> on T5 since I've loved using T4 for the last few years, and it does
>> seem to be a step forward.
>>
>> I think its common to want to just get something working in order to
>> get a feel for the framework. Doing so in Tapestry, at least for me,
>> has been a waste of two days. I finally, on the third day, I have
>> something that appears to allow the tutorial to work with basic
>> security. I'm not sure if others have similar problems and just gave
>> up without comment, making other frameworks seem more popular?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>
>>> I recently had an e-mail exchange with a Tapestry user; after
>>> congratulating me on creating Tapestry, he went on with the  
>>> following
>>> observation on his organization: The company I work at unfortunately
>>> chose JSF for their big app. The reason was that Tapestry was  
>>> "brittle"
>>> in the sense that, if one developer breaks something, on a page or a
>>> service, very often the whole site won't come up because the initial
>>> registry startup will fail. Or for example, if page A has a  
>>> pagelink to
>>> page B, and page B is broken, then page A won't render. While I  
>>> agree
>>> that we shouldn't ship unless the whole app is working, this is a
>>> thousands of pages big app with hundreds of mediocre (as in likely  
>>> to
>>> break things) developers. They'd rather have 80% of the thing  
>>> working
>>> than nothing at all. I never thought of this for my own projects,  
>>> and
>>> haven't had the time to examine the truth of their claims. What's  
>>> your
>>> take?
>>> I provided the following response:
>>> Early failures are absolutely, 100%, the only path towards code
>>> quality. You may have heard the phrase "no broken windows" (see "The
>>> Tipping Point" by Malcom Gladwell for more details) but the short  
>>> form
>>> is that when errors go uncorrected (whether they are broken  
>>> windows in
>>> an abandoned building, or broken code in an application) they tend  
>>> to
>>> multiply quite rapidly.
>>> The things that will "break" a link from page A to page B are
>>> substantial problems such as invalid templates, references to  
>>> unknown
>>> properties or components, or compile errors in the page B class ...
>>> things that no other developer should ever see when page B's  
>>> developer
>>> is working and checking in code. That is, problems that should  
>>> never be
>>> checked into trunk, but instead kept in a local workspace or a  
>>> private
>>> branch.
>>> An organization that thinks that fail early is a problem is an
>>> organization that isn't prepared to develop a large application in  
>>> any
>>> technology. The image I'm getting is one where there is no build
>>> server, no continuous integration, at best CVS for source code
>>> management (or possibly one of those "shared directory"
>>> monstrosities) .... i.e., a chaotic environment where errors are
>>> allowed to be checked in to the trunk and can go unnoticed for some
>>> time.
>>> The solution to coding errors in pages or components is not to wait
>>> until your testers (or end users) find the bugs, but to identify and
>>> fix the bugs early. That's called "engineering discipline" and the
>>> reality is that even self-professed "mediocre" developers can do it.
>>> Tapestry helps because it fails early and has great exception  
>>> reporting
>>> to guide you right the problem so that you can fix it.
>>> Another factor here is enforced helplessness. If only Fred  
>>> understands
>>> page B and he's out when it's broken, then all development stops
>>> waiting for Fred to get back. I hit this problem myself, years ago
>>> working on a large Struts application (those words give me the  
>>> heebie
>>> jeebies now!). We had lots of code, a fragile and slow build  
>>> process,
>>> and many little code "fiefdoms". I spent too much wasted time  
>>> twiddling
>>> my thumbs.
>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>> normally develops page A) should be free to fix it. Julie will  
>>> need to
>>> understand the page B code well enough to fix it, but also you  
>>> need an
>>> overall environment with shared source, no repository locks (that  
>>> is,
>>> nothing that says "Only Fred can change this file"), and no  
>>> management
>>> PHB's getting in the way. Pair programming is the best way for  
>>> Fred and
>>> Julie to share knowledge so that they can understand each other's  
>>> code.
>>> Even if pairing occurs only part time, it's very effective at  
>>> knowledge
>>> transfer as well as ordinary coding.
>>> The idea that "mediocre" developers should use JSF as it is more
>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>> productivity for all developers, by streamlining, simplifying, being
>>> smart and being concise ... not to mention live class reloading and
>>> best-of-breed exception reporting, which makes it fast to identify  
>>> and
>>> fix those errors.
>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>> should switch to a diet of fried chicken three meals a day!  
>>> Likewise,
>>> if you have concerns with code quality from your developers, you  
>>> should
>>> not switch to a less agile, more code-intensive, less supportive
>>> development model and hope to catch all the bugs in QA. Sweeping
>>> problems under the rug is never a winning strategy.
>>> Coming down off my soap box, I should also add that Tapestry 5.1  
>>> works
>>> a little bit differently than 5.0 in this respect, so it does (in  
>>> fact)
>>> defer more of the page loading and validation until a link is  
>>> actually
>>> clicked. This is more for performance reasons than to shield  
>>> developers
>>> from application problems. Even in 5.0, the loading and validation  
>>> was
>>> the "reach" from page A to pages explicitly referenced (usually via
>>> PageLink during the rendering of page A), so it's a highly unlikely
>>> case that a single error in a 1000 page application will keep the
>>> application from starting up, unless the start page of the  
>>> application
>>> links to all 999 other pages.
>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>> quality problems. Quality problems lead to development failures,
>>> schedule slips, missing functionality, low morale and high turnover.
>>> Saying "we don't have time to fix the quality problem first" is to
>>> ignore the the second law of Thermodynamics. You are expecting a
>>> miracle, literally writing it into your project plan.
>>> Formos addresses this issue two ways: First, we use Scrum and  
>>> deliver
>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>> constant check on quality (we're providing working code  
>>> constantly). We
>>> don't even try to predict what we'll be doing six months or two  
>>> years
>>> from now, we just deliver a steady, manageable stream of software.
>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>> anonymous developer's organization rejected it, and for many, many  
>>> more
>>> reasons besides.
>>>
>>> -- 
>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>
>>
>
> -- 
> ==================================================
> dott. Ivano Mario Luberti
> Archimede Informatica societa' cooperativa a r. l.
> Sede Operativa
> Via Gereschi 36 - 56126- Pisa
> tel.: +39-050- 580959
> tel/fax: +39-050-9711344
> web: www.archicoop.it
> ==================================================
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

Re: [Tapestry Central] Why chose Tapestry?

[Ivano Luberti <lu...@archicoop.it>]

Well Thiago I would say that Eclipse 3.4 is a big step forward with
respect to 3.3 and even more with respect to 3.2 and 3.1.


Thiago H. de Paula Figueiredo ha scritto:
>
> I've never used Tapestry with WTP, but I don't know why it wouldn't
> work. By the way, I've used WTP before in other projects a couple
> years ago and I hated it. I used Sysdeo's Tomcat Launcher and an
> exploded WAR project structure. No deploying needed in development.
>
>   
neither in Eclise3.4


>> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
>> versioning and ANT to generate deployments.
>>     
>
> You don't need to use Maven to work with Tapestry. Just do the
> dependency management yourself, like you already do with T4.
>
>   
Ok , great

-- 
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Thu, Jun 18, 2009 at 9:46 AM, Ivano Luberti<lu...@archicoop.it> wrote:
> I'm a T4 user that is evaluating if to move to T5.
> If I well understand Norman message, it is not possible to develop with
> T5 using Eclipse3.4 with WTP like with T4?

I've never used Tapestry with WTP, but I don't know why it wouldn't
work. By the way, I've used WTP before in other projects a couple
years ago and I hated it. I used Sysdeo's Tomcat Launcher and an
exploded WAR project structure. No deploying needed in development.

> I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
> versioning and ANT to generate deployments.

You don't need to use Maven to work with Tapestry. Just do the
dependency management yourself, like you already do with T4.

-- 
Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Ivano Luberti <lu...@archicoop.it>]

I'm a T4 user that is evaluating if to move to T5.
If I well understand Norman message, it is not possible to develop with
T5 using Eclipse3.4 with WTP like with T4?

I work in a small company: we use Eclipse 3.4 with WTP. We use SVN for
versioning and ANT to generate deployments.

To introduce Maven would be really time consuming and hence exepnsive.



Norman Franke ha scritto:
> I've been using T4/4.1 for several years and have been quite pleased
> with it. I've been using it with Hibernate, and while not perfect,
> it's worked pretty well. We've found it much faster to embed a web
> browser in our main app and do editing, queries and the like via
> Tapestry than writing native code.
>
> I have a new project to replace our aging billing system. I figured
> this would be a great way to learn T5. So, I'm migrating me, not an
> app. :-)
>
> I was pondering posting this, but this thread sort of pushed me over
> the top. Note that I don't disagree with anything Howard said.
> However, this almost became "Why I almost dumped Tapestry entirely."
>
> I'm writing this in order to solicit feedback and maybe help others.
> I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
> time time, and I'm very productive developing use them (and T4.1) I
> think this is a pretty common development environment.
>
> To get started in T5 for a fresh new app, my first thought was to
> follow the tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>
> Chapter 2 just plain didn't work for me. I think part of it is due to
> Maven generally being extremely fragile and working less than half of
> the time. However, even after working around that, you can't just
> import the project into Eclipse. At least not under Eclipse 3.4.2.
>
> No problem, I thought. Maven is annoying anyway. I'll just create a
> Dynamic Web project (like I do for T4.1) and download the T5.1 binary
> distribution. That's even worse. It comes with no README listing
> dependencies or anything useful, and includes tons of libraries that
> don't appear to be even needed. Tapestry failed to start up during
> initialization. Why have a binary distro that doesn't work?
>
> Back to Maven. After some googling, I found this article:
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) Shouldn't
> this be included in the tutorial? Sadly, the tutorial is extremely
> basic, but at least it works. (And is the only way I've found to
> actually create a new project in Eclipse to date.)
>
> Next, I tried Tapestry Jumpstart. After hours of configuration and
> random errors (using Tomcat), it worked. However, it's so fragile and
> klugy that I just can't see using it in production. I don't care about
> OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a
> remote tomcat sessions eliminates many of the developer productivity
> benefits of T5 in the first place. One thing I liked about T4 was that
> I could deploy a WAR to a stock Tomcat install, and it would just
> work. That won't happen with Jumpstart. Plus. it if takes 3 hours to
> just get a working developer environment, why even bother?
>
> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
> Sadly, AppFuse's T4 support is now broken due to a dependancy on
> tapestry-flash that appears to be missing and following the
> instructions on the AppFuse Tapestry 5 page doesn't work anymore
> either, resulting in tons of missing resources.
>
> So, since T5 doesn't appear to provide much in the way of
> authentication / security (a very basic requirement for almost all
> webapps), I started down the tapestry5-acegi approach. Of course, that
> doesn't work with T5.1. I managed to get it working and then upgraded
> to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without
> augmentation. (Thanks to maven for not updating the packages when I
> switched to the snapshot, too. I had to delete the "nu" directory in
> my ~/.m2 directory. One more reason Maven blows. It just doesn't do
> what you want.)
>
> I'd love to see more people use Tapestry, but after attempting a new
> project, I'd feel embarrassed asking people to give Tapestry a look at
> this point. Heck, I'm thinking maybe sticking with T4.1 is the way to
> go, despite all the benefits of T5. But, I really do want to start in
> on T5 since I've loved using T4 for the last few years, and it does
> seem to be a step forward.
>
> I think its common to want to just get something working in order to
> get a feel for the framework. Doing so in Tapestry, at least for me,
> has been a waste of two days. I finally, on the third day, I have
> something that appears to allow the tutorial to work with basic
> security. I'm not sure if others have similar problems and just gave
> up without comment, making other frameworks seem more popular?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>
>> I recently had an e-mail exchange with a Tapestry user; after
>> congratulating me on creating Tapestry, he went on with the following
>> observation on his organization: The company I work at unfortunately
>> chose JSF for their big app. The reason was that Tapestry was "brittle"
>> in the sense that, if one developer breaks something, on a page or a
>> service, very often the whole site won't come up because the initial
>> registry startup will fail. Or for example, if page A has a pagelink to
>> page B, and page B is broken, then page A won't render. While I agree
>> that we shouldn't ship unless the whole app is working, this is a
>> thousands of pages big app with hundreds of mediocre (as in likely to
>> break things) developers. They'd rather have 80% of the thing working
>> than nothing at all. I never thought of this for my own projects, and
>> haven't had the time to examine the truth of their claims. What's your
>> take?
>> I provided the following response:
>> Early failures are absolutely, 100%, the only path towards code
>> quality. You may have heard the phrase "no broken windows" (see "The
>> Tipping Point" by Malcom Gladwell for more details) but the short form
>> is that when errors go uncorrected (whether they are broken windows in
>> an abandoned building, or broken code in an application) they tend to
>> multiply quite rapidly.
>> The things that will "break" a link from page A to page B are
>> substantial problems such as invalid templates, references to unknown
>> properties or components, or compile errors in the page B class ...
>> things that no other developer should ever see when page B's developer
>> is working and checking in code. That is, problems that should never be
>> checked into trunk, but instead kept in a local workspace or a private
>> branch.
>> An organization that thinks that fail early is a problem is an
>> organization that isn't prepared to develop a large application in any
>> technology. The image I'm getting is one where there is no build
>> server, no continuous integration, at best CVS for source code
>> management (or possibly one of those "shared directory"
>> monstrosities) .... i.e., a chaotic environment where errors are
>> allowed to be checked in to the trunk and can go unnoticed for some
>> time.
>> The solution to coding errors in pages or components is not to wait
>> until your testers (or end users) find the bugs, but to identify and
>> fix the bugs early. That's called "engineering discipline" and the
>> reality is that even self-professed "mediocre" developers can do it.
>> Tapestry helps because it fails early and has great exception reporting
>> to guide you right the problem so that you can fix it.
>> Another factor here is enforced helplessness. If only Fred understands
>> page B and he's out when it's broken, then all development stops
>> waiting for Fred to get back. I hit this problem myself, years ago
>> working on a large Struts application (those words give me the heebie
>> jeebies now!). We had lots of code, a fragile and slow build process,
>> and many little code "fiefdoms". I spent too much wasted time twiddling
>> my thumbs.
>> Nobody should "own the code"; if page B is is broken, Julie (who
>> normally develops page A) should be free to fix it. Julie will need to
>> understand the page B code well enough to fix it, but also you need an
>> overall environment with shared source, no repository locks (that is,
>> nothing that says "Only Fred can change this file"), and no management
>> PHB's getting in the way. Pair programming is the best way for Fred and
>> Julie to share knowledge so that they can understand each other's code.
>> Even if pairing occurs only part time, it's very effective at knowledge
>> transfer as well as ordinary coding.
>> The idea that "mediocre" developers should use JSF as it is more
>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>> productivity for all developers, by streamlining, simplifying, being
>> smart and being concise ... not to mention live class reloading and
>> best-of-breed exception reporting, which makes it fast to identify and
>> fix those errors.
>> If your doctor tells you to eat less red meat, that doesn't mean you
>> should switch to a diet of fried chicken three meals a day! Likewise,
>> if you have concerns with code quality from your developers, you should
>> not switch to a less agile, more code-intensive, less supportive
>> development model and hope to catch all the bugs in QA. Sweeping
>> problems under the rug is never a winning strategy.
>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>> a little bit differently than 5.0 in this respect, so it does (in fact)
>> defer more of the page loading and validation until a link is actually
>> clicked. This is more for performance reasons than to shield developers
>> from application problems. Even in 5.0, the loading and validation was
>> the "reach" from page A to pages explicitly referenced (usually via
>> PageLink during the rendering of page A), so it's a highly unlikely
>> case that a single error in a 1000 page application will keep the
>> application from starting up, unless the start page of the application
>> links to all 999 other pages.
>> Re-reading the above post I can't emphasize enough: you can't ignore
>> quality problems. Quality problems lead to development failures,
>> schedule slips, missing functionality, low morale and high turnover.
>> Saying "we don't have time to fix the quality problem first" is to
>> ignore the the second law of Thermodynamics. You are expecting a
>> miracle, literally writing it into your project plan.
>> Formos addresses this issue two ways: First, we use Scrum and deliver
>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>> constant check on quality (we're providing working code constantly). We
>> don't even try to predict what we'll be doing six months or two years
>> from now, we just deliver a steady, manageable stream of software.
>> Secondly, Formos uses Tapestry because of all the reasons that the
>> anonymous developer's organization rejected it, and for many, many more
>> reasons besides.
>>
>> -- 
>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>
>

-- 
==================================================
dott. Ivano Mario Luberti
Archimede Informatica societa' cooperativa a r. l.
Sede Operativa
Via Gereschi 36 - 56126- Pisa
tel.: +39-050- 580959
tel/fax: +39-050-9711344
web: www.archicoop.it
==================================================


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Ville Virtanen <vi...@cerion.fi>]

Hi,

First we used eclipse too, but ran in far too many problems with maven.
Today we use NetBeans, which seems to do most of the things that we expect
it to. At first there was _really_ much resistance to start using NetBeans
which was seen as toy and not as an IDE for professional developer, but in
my opinion if you want an environment that _just_ works, use NetBeans.
(Especially if your developers aren't that familiar with Eclipse.)

Maven also caused a lot of trouble for us at the beginning. Some devs didn't
have any problems, some had more. The more resistance the dev had, the more
problems he/she also had...

Anyway, today when new developer starts (s)he installs maven, svn tortoise,
netbeans and downloads the project and then starts the app with mvn
jetty:run -> dev is ready to start coding. This process usually takes about
45 minutes, depending how long the machine downloads stuff and installs
java/netbeans. 

The start of new project does not take any longer than T4 project, but I
must admit that there is some learning curve when you come from T4 or some
other environments, after all, this is new and different system. However, it
is not black magic, and if you have experience with systems it shouldn't be
that hard.

The documentation is lacking, and is the next thing to be fixed (As Howard
has mentioned.). Also T5 should be as new-user-friendly as possible, which
clearly could be improved?

 - Ville


Norman Franke-2 wrote:
> 
> I've been using T4/4.1 for several years and have been quite pleased  
> with it. I've been using it with Hibernate, and while not perfect,  
> it's worked pretty well. We've found it much faster to embed a web  
> browser in our main app and do editing, queries and the like via  
> Tapestry than writing native code.
> 
> I have a new project to replace our aging billing system. I figured  
> this would be a great way to learn T5. So, I'm migrating me, not an  
> app. :-)
> 
> I was pondering posting this, but this thread sort of pushed me over  
> the top. Note that I don't disagree with anything Howard said.  
> However, this almost became "Why I almost dumped Tapestry entirely."
> 
> I'm writing this in order to solicit feedback and maybe help others.  
> I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite  
> time time, and I'm very productive developing use them (and T4.1) I  
> think this is a pretty common development environment.
> 
> To get started in T5 for a fresh new app, my first thought was to  
> follow the tutorial at http://tapestry.apache.org/tapestry5.1/ 
> tutorial1/.
> 
> Chapter 2 just plain didn't work for me. I think part of it is due to  
> Maven generally being extremely fragile and working less than half of  
> the time. However, even after working around that, you can't just  
> import the project into Eclipse. At least not under Eclipse 3.4.2.
> 
> No problem, I thought. Maven is annoying anyway. I'll just create a  
> Dynamic Web project (like I do for T4.1) and download the T5.1 binary  
> distribution. That's even worse. It comes with no README listing  
> dependencies or anything useful, and includes tons of libraries that  
> don't appear to be even needed. Tapestry failed to start up during  
> initialization. Why have a binary distro that doesn't work?
> 
> Back to Maven. After some googling, I found this article:
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) 
>   Shouldn't this be included in the tutorial? Sadly, the tutorial is  
> extremely basic, but at least it works. (And is the only way I've  
> found to actually create a new project in Eclipse to date.)
> 
> Next, I tried Tapestry Jumpstart. After hours of configuration and  
> random errors (using Tomcat), it worked. However, it's so fragile and  
> klugy that I just can't see using it in production. I don't care about  
> OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a  
> remote tomcat sessions eliminates many of the developer productivity  
> benefits of T5 in the first place. One thing I liked about T4 was that  
> I could deploy a WAR to a stock Tomcat install, and it would just  
> work. That won't happen with Jumpstart. Plus. it if takes 3 hours to  
> just get a working developer environment, why even bother?
> 
> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.  
> Sadly, AppFuse's T4 support is now broken due to a dependancy on  
> tapestry-flash that appears to be missing and following the  
> instructions on the AppFuse Tapestry 5 page doesn't work anymore  
> either, resulting in tons of missing resources.
> 
> So, since T5 doesn't appear to provide much in the way of  
> authentication / security (a very basic requirement for almost all  
> webapps), I started down the tapestry5-acegi approach. Of course, that  
> doesn't work with T5.1. I managed to get it working and then upgraded  
> to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without  
> augmentation. (Thanks to maven for not updating the packages when I  
> switched to the snapshot, too. I had to delete the "nu" directory in  
> my ~/.m2 directory. One more reason Maven blows. It just doesn't do  
> what you want.)
> 
> I'd love to see more people use Tapestry, but after attempting a new  
> project, I'd feel embarrassed asking people to give Tapestry a look at  
> this point. Heck, I'm thinking maybe sticking with T4.1 is the way to  
> go, despite all the benefits of T5. But, I really do want to start in  
> on T5 since I've loved using T4 for the last few years, and it does  
> seem to be a step forward.
> 
> I think its common to want to just get something working in order to  
> get a feel for the framework. Doing so in Tapestry, at least for me,  
> has been a waste of two days. I finally, on the third day, I have  
> something that appears to allow the tutorial to work with basic  
> security. I'm not sure if others have similar problems and just gave  
> up without comment, making other frameworks seem more popular?
> 
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
> 
> 
> 
> On Jun 16, 2009, at 7:20 PM, Howard wrote:
> 
>> I recently had an e-mail exchange with a Tapestry user; after
>> congratulating me on creating Tapestry, he went on with the following
>> observation on his organization: The company I work at unfortunately
>> chose JSF for their big app. The reason was that Tapestry was  
>> "brittle"
>> in the sense that, if one developer breaks something, on a page or a
>> service, very often the whole site won't come up because the initial
>> registry startup will fail. Or for example, if page A has a pagelink  
>> to
>> page B, and page B is broken, then page A won't render. While I agree
>> that we shouldn't ship unless the whole app is working, this is a
>> thousands of pages big app with hundreds of mediocre (as in likely to
>> break things) developers. They'd rather have 80% of the thing working
>> than nothing at all. I never thought of this for my own projects, and
>> haven't had the time to examine the truth of their claims. What's your
>> take?
>> I provided the following response:
>> Early failures are absolutely, 100%, the only path towards code
>> quality. You may have heard the phrase "no broken windows" (see "The
>> Tipping Point" by Malcom Gladwell for more details) but the short form
>> is that when errors go uncorrected (whether they are broken windows in
>> an abandoned building, or broken code in an application) they tend to
>> multiply quite rapidly.
>> The things that will "break" a link from page A to page B are
>> substantial problems such as invalid templates, references to unknown
>> properties or components, or compile errors in the page B class ...
>> things that no other developer should ever see when page B's developer
>> is working and checking in code. That is, problems that should never  
>> be
>> checked into trunk, but instead kept in a local workspace or a private
>> branch.
>> An organization that thinks that fail early is a problem is an
>> organization that isn't prepared to develop a large application in any
>> technology. The image I'm getting is one where there is no build
>> server, no continuous integration, at best CVS for source code
>> management (or possibly one of those "shared directory"
>> monstrosities) .... i.e., a chaotic environment where errors are
>> allowed to be checked in to the trunk and can go unnoticed for some
>> time.
>> The solution to coding errors in pages or components is not to wait
>> until your testers (or end users) find the bugs, but to identify and
>> fix the bugs early. That's called "engineering discipline" and the
>> reality is that even self-professed "mediocre" developers can do it.
>> Tapestry helps because it fails early and has great exception  
>> reporting
>> to guide you right the problem so that you can fix it.
>> Another factor here is enforced helplessness. If only Fred understands
>> page B and he's out when it's broken, then all development stops
>> waiting for Fred to get back. I hit this problem myself, years ago
>> working on a large Struts application (those words give me the heebie
>> jeebies now!). We had lots of code, a fragile and slow build process,
>> and many little code "fiefdoms". I spent too much wasted time  
>> twiddling
>> my thumbs.
>> Nobody should "own the code"; if page B is is broken, Julie (who
>> normally develops page A) should be free to fix it. Julie will need to
>> understand the page B code well enough to fix it, but also you need an
>> overall environment with shared source, no repository locks (that is,
>> nothing that says "Only Fred can change this file"), and no management
>> PHB's getting in the way. Pair programming is the best way for Fred  
>> and
>> Julie to share knowledge so that they can understand each other's  
>> code.
>> Even if pairing occurs only part time, it's very effective at  
>> knowledge
>> transfer as well as ordinary coding.
>> The idea that "mediocre" developers should use JSF as it is more
>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>> productivity for all developers, by streamlining, simplifying, being
>> smart and being concise ... not to mention live class reloading and
>> best-of-breed exception reporting, which makes it fast to identify and
>> fix those errors.
>> If your doctor tells you to eat less red meat, that doesn't mean you
>> should switch to a diet of fried chicken three meals a day! Likewise,
>> if you have concerns with code quality from your developers, you  
>> should
>> not switch to a less agile, more code-intensive, less supportive
>> development model and hope to catch all the bugs in QA. Sweeping
>> problems under the rug is never a winning strategy.
>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>> a little bit differently than 5.0 in this respect, so it does (in  
>> fact)
>> defer more of the page loading and validation until a link is actually
>> clicked. This is more for performance reasons than to shield  
>> developers
>> from application problems. Even in 5.0, the loading and validation was
>> the "reach" from page A to pages explicitly referenced (usually via
>> PageLink during the rendering of page A), so it's a highly unlikely
>> case that a single error in a 1000 page application will keep the
>> application from starting up, unless the start page of the application
>> links to all 999 other pages.
>> Re-reading the above post I can't emphasize enough: you can't ignore
>> quality problems. Quality problems lead to development failures,
>> schedule slips, missing functionality, low morale and high turnover.
>> Saying "we don't have time to fix the quality problem first" is to
>> ignore the the second law of Thermodynamics. You are expecting a
>> miracle, literally writing it into your project plan.
>> Formos addresses this issue two ways: First, we use Scrum and deliver
>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>> constant check on quality (we're providing working code constantly).  
>> We
>> don't even try to predict what we'll be doing six months or two years
>> from now, we just deliver a steady, manageable stream of software.
>> Secondly, Formos uses Tapestry because of all the reasons that the
>> anonymous developer's organization rejected it, and for many, many  
>> more
>> reasons besides.
>>
>> --
>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp24064891p24088695.html
Sent from the Tapestry - User mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Sparqle <ds...@gmail.com>]

I agree with Juan. This is the biggest barrier to Tapestry adoption. 
Most people I know who are working even for big corporations are not used to
Maven. In fact I know at least 100 developers from various companies in our
area and nobody uses Maven. Most people want a dynamic web project in
eclipse with the ability to export/import the application from/into eclipse
as a war file.

I have wasted a lot of time myself with Tapestry5 already. Most of the
articles and examples either don't work or are incomplete. I think Tapestry5
is probably very innovative, easy and fast, but getting the development
environment setup right is very tough (without maven). The other problem is
the understanding the best practices for Spring, Hibernate integration etc.
The Jumpstart application tries to do this. 

It would be nice if the Jumpstart application was available as a war file
(with sources) which could then be imported as a regular Dynamic web project
in Eclipse. But to get Jumpstart to work on Eclipse is a marathon activity
with thousands of steps. I gave up. How about 1 step: simple war file with
all the sources that is easy to import into Eclipse? 

The Tapestry4NonBelievers site does this, but their war file is not
compatible with the latest Tapestry releases. Also, that application is very
small with only a few concepts being covered.

I have used other frameworks (specifically ZK) that are very well documented
and easy to use, come with a comprehensive set of examples that is easy to
download and setup. Even Wicket has a good demo application (as war file
with sources) that ships with every release that just works.

It would be really helpful if every release of Tapestry shipped with a
standard demo project (like the Spring Petshop or ZK Explorer or Seam Hotel
Reservation) with all the best practices illustrated (Spring/Hibernate
integration etc). 

Without a book, and no working example code that can easily be installed
(without maven), it is very hard to learn the framework (however simple the
framework might be).






Juan E. Maya wrote:
> 
> did u follow the tapestry quickstart in
> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> could get easier than this. U can even run it inside eclipse if u have
> the m2 plugin for maven.
> 
> i do agree with u that the documentation could be better, however,
> reading your message somebody could believe that starting a new
> tapestry project is extremely difficult and it's totally the contrary.
> 
> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com> wrote:
>> I've been using T4/4.1 for several years and have been quite pleased with
>> it. I've been using it with Hibernate, and while not perfect, it's worked
>> pretty well. We've found it much faster to embed a web browser in our
>> main
>> app and do editing, queries and the like via Tapestry than writing native
>> code.
>>
>> I have a new project to replace our aging billing system. I figured this
>> would be a great way to learn T5. So, I'm migrating me, not an app. :-)
>>
>> I was pondering posting this, but this thread sort of pushed me over the
>> top. Note that I don't disagree with anything Howard said. However, this
>> almost became "Why I almost dumped Tapestry entirely."
>>
>> I'm writing this in order to solicit feedback and maybe help others. I've
>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time
>> time,
>> and I'm very productive developing use them (and T4.1) I think this is a
>> pretty common development environment.
>>
>> To get started in T5 for a fresh new app, my first thought was to follow
>> the
>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>
>> Chapter 2 just plain didn't work for me. I think part of it is due to
>> Maven
>> generally being extremely fragile and working less than half of the time.
>> However, even after working around that, you can't just import the
>> project
>> into Eclipse. At least not under Eclipse 3.4.2.
>>
>> No problem, I thought. Maven is annoying anyway. I'll just create a
>> Dynamic
>> Web project (like I do for T4.1) and download the T5.1 binary
>> distribution.
>> That's even worse. It comes with no README listing dependencies or
>> anything
>> useful, and includes tons of libraries that don't appear to be even
>> needed.
>> Tapestry failed to start up during initialization. Why have a binary
>> distro
>> that doesn't work?
>>
>> Back to Maven. After some googling, I found this article:
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) Shouldn't
>> this be included in the tutorial? Sadly, the tutorial is extremely basic,
>> but at least it works. (And is the only way I've found to actually create
>> a
>> new project in Eclipse to date.)
>>
>> Next, I tried Tapestry Jumpstart. After hours of configuration and random
>> errors (using Tomcat), it worked. However, it's so fragile and klugy that
>> I
>> just can't see using it in production. I don't care about OpenEJB. I want
>> just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions
>> eliminates many of the developer productivity benefits of T5 in the first
>> place. One thing I liked about T4 was that I could deploy a WAR to a
>> stock
>> Tomcat install, and it would just work. That won't happen with Jumpstart.
>> Plus. it if takes 3 hours to just get a working developer environment,
>> why
>> even bother?
>>
>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly,
>> AppFuse's T4 support is now broken due to a dependancy on tapestry-flash
>> that appears to be missing and following the instructions on the AppFuse
>> Tapestry 5 page doesn't work anymore either, resulting in tons of missing
>> resources.
>>
>> So, since T5 doesn't appear to provide much in the way of authentication
>> /
>> security (a very basic requirement for almost all webapps), I started
>> down
>> the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I
>> managed to get it working and then upgraded to tapestry-spring-security
>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven
>> for
>> not updating the packages when I switched to the snapshot, too. I had to
>> delete the "nu" directory in my ~/.m2 directory. One more reason Maven
>> blows. It just doesn't do what you want.)
>>
>> I'd love to see more people use Tapestry, but after attempting a new
>> project, I'd feel embarrassed asking people to give Tapestry a look at
>> this
>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to go,
>> despite
>> all the benefits of T5. But, I really do want to start in on T5 since
>> I've
>> loved using T4 for the last few years, and it does seem to be a step
>> forward.
>>
>> I think its common to want to just get something working in order to get
>> a
>> feel for the framework. Doing so in Tapestry, at least for me, has been a
>> waste of two days. I finally, on the third day, I have something that
>> appears to allow the tutorial to work with basic security. I'm not sure
>> if
>> others have similar problems and just gave up without comment, making
>> other
>> frameworks seem more popular?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>
>>> I recently had an e-mail exchange with a Tapestry user; after
>>> congratulating me on creating Tapestry, he went on with the following
>>> observation on his organization: The company I work at unfortunately
>>> chose JSF for their big app. The reason was that Tapestry was "brittle"
>>> in the sense that, if one developer breaks something, on a page or a
>>> service, very often the whole site won't come up because the initial
>>> registry startup will fail. Or for example, if page A has a pagelink to
>>> page B, and page B is broken, then page A won't render. While I agree
>>> that we shouldn't ship unless the whole app is working, this is a
>>> thousands of pages big app with hundreds of mediocre (as in likely to
>>> break things) developers. They'd rather have 80% of the thing working
>>> than nothing at all. I never thought of this for my own projects, and
>>> haven't had the time to examine the truth of their claims. What's your
>>> take?
>>> I provided the following response:
>>> Early failures are absolutely, 100%, the only path towards code
>>> quality. You may have heard the phrase "no broken windows" (see "The
>>> Tipping Point" by Malcom Gladwell for more details) but the short form
>>> is that when errors go uncorrected (whether they are broken windows in
>>> an abandoned building, or broken code in an application) they tend to
>>> multiply quite rapidly.
>>> The things that will "break" a link from page A to page B are
>>> substantial problems such as invalid templates, references to unknown
>>> properties or components, or compile errors in the page B class ...
>>> things that no other developer should ever see when page B's developer
>>> is working and checking in code. That is, problems that should never be
>>> checked into trunk, but instead kept in a local workspace or a private
>>> branch.
>>> An organization that thinks that fail early is a problem is an
>>> organization that isn't prepared to develop a large application in any
>>> technology. The image I'm getting is one where there is no build
>>> server, no continuous integration, at best CVS for source code
>>> management (or possibly one of those "shared directory"
>>> monstrosities) .... i.e., a chaotic environment where errors are
>>> allowed to be checked in to the trunk and can go unnoticed for some
>>> time.
>>> The solution to coding errors in pages or components is not to wait
>>> until your testers (or end users) find the bugs, but to identify and
>>> fix the bugs early. That's called "engineering discipline" and the
>>> reality is that even self-professed "mediocre" developers can do it.
>>> Tapestry helps because it fails early and has great exception reporting
>>> to guide you right the problem so that you can fix it.
>>> Another factor here is enforced helplessness. If only Fred understands
>>> page B and he's out when it's broken, then all development stops
>>> waiting for Fred to get back. I hit this problem myself, years ago
>>> working on a large Struts application (those words give me the heebie
>>> jeebies now!). We had lots of code, a fragile and slow build process,
>>> and many little code "fiefdoms". I spent too much wasted time twiddling
>>> my thumbs.
>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>> normally develops page A) should be free to fix it. Julie will need to
>>> understand the page B code well enough to fix it, but also you need an
>>> overall environment with shared source, no repository locks (that is,
>>> nothing that says "Only Fred can change this file"), and no management
>>> PHB's getting in the way. Pair programming is the best way for Fred and
>>> Julie to share knowledge so that they can understand each other's code.
>>> Even if pairing occurs only part time, it's very effective at knowledge
>>> transfer as well as ordinary coding.
>>> The idea that "mediocre" developers should use JSF as it is more
>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>> productivity for all developers, by streamlining, simplifying, being
>>> smart and being concise ... not to mention live class reloading and
>>> best-of-breed exception reporting, which makes it fast to identify and
>>> fix those errors.
>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>> should switch to a diet of fried chicken three meals a day! Likewise,
>>> if you have concerns with code quality from your developers, you should
>>> not switch to a less agile, more code-intensive, less supportive
>>> development model and hope to catch all the bugs in QA. Sweeping
>>> problems under the rug is never a winning strategy.
>>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>>> a little bit differently than 5.0 in this respect, so it does (in fact)
>>> defer more of the page loading and validation until a link is actually
>>> clicked. This is more for performance reasons than to shield developers
>>> from application problems. Even in 5.0, the loading and validation was
>>> the "reach" from page A to pages explicitly referenced (usually via
>>> PageLink during the rendering of page A), so it's a highly unlikely
>>> case that a single error in a 1000 page application will keep the
>>> application from starting up, unless the start page of the application
>>> links to all 999 other pages.
>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>> quality problems. Quality problems lead to development failures,
>>> schedule slips, missing functionality, low morale and high turnover.
>>> Saying "we don't have time to fix the quality problem first" is to
>>> ignore the the second law of Thermodynamics. You are expecting a
>>> miracle, literally writing it into your project plan.
>>> Formos addresses this issue two ways: First, we use Scrum and deliver
>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>> constant check on quality (we're providing working code constantly). We
>>> don't even try to predict what we'll be doing six months or two years
>>> from now, we just deliver a steady, manageable stream of software.
>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>> anonymous developer's organization rejected it, and for many, many more
>>> reasons besides.
>>>
>>> --
>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp3089605p3095979.html
Sent from the Tapestry Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

["Thiago H. de Paula Figueiredo" <th...@gmail.com>]

On Thu, Jun 18, 2009 at 1:59 AM, Craig St. Jean<cr...@gmail.com> wrote:
> Further, there have been too many places where Tapestry 5 does not work with
> X environment (i.e. JBoss 4 or 5 or Glassfish, without modifications) and it
> just gets brushed off as "its not our problem, somethings wrong with X"

Because, most of the time, these problems are not in Tapestry code and
aren't fixable in Tapestry itself. ;)

> Though I haven't seen anyone trying to import/export a WAR into Eclipse,
> that one kind of surprised me.  All of the Java developers I know (except
> for 1) won't touch Maven, and use project specific Ant scripts on a
> continuous integration server.  The only place where I've found Maven
> convenient is just for obtaining library dependencies.  I then copy them and
> throw Maven away.

You can use Maven 2 dependency features in Ant
(http://maven.apache.org/ant-tasks/index.html) without Maven itself.

-- 
Thiago

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

["Craig St. Jean" <cr...@gmail.com>]

Sparqle,
You've hit on exactly the same problems I've seen with Tapestry.

Further, there have been too many places where Tapestry 5 does not work with
X environment (i.e. JBoss 4 or 5 or Glassfish, without modifications) and it
just gets brushed off as "its not our problem, somethings wrong with X"

Though I haven't seen anyone trying to import/export a WAR into Eclipse,
that one kind of surprised me.  All of the Java developers I know (except
for 1) won't touch Maven, and use project specific Ant scripts on a
continuous integration server.  The only place where I've found Maven
convenient is just for obtaining library dependencies.  I then copy them and
throw Maven away.

On Wed, Jun 17, 2009 at 6:28 PM, Sparqle <ds...@gmail.com> wrote:

>
> I agree with Juan. This is the biggest barrier to Tapestry adoption.
> Most people I know who are working even for big corporations are not used
> to
> Maven. In fact I know at least 100 developers from various companies in our
> area and nobody uses Maven. Most people want a dynamic web project in
> eclipse with the ability to export/import the application from/into eclipse
> as a war file.
>
> I have wasted a lot of time myself with Tapestry5 already. Most of the
> articles and examples either don't work or are incomplete. I think
> Tapestry5
> is probably very innovative, easy and fast, but getting the development
> environment setup right is very tough (without maven). The other problem is
> the understanding the best practices for Spring, Hibernate integration etc.
> The Jumpstart application tries to do this.
>
> It would be nice if the Jumpstart application was available as a war file
> (with sources) which could then be imported as a regular Dynamic web
> project
> in Eclipse. But to get Jumpstart to work on Eclipse is a marathon activity
> with thousands of steps. I gave up. How about 1 step: simple war file with
> all the sources that is easy to import into Eclipse?
>
> The Tapestry4NonBelievers site does this, but their war file is not
> compatible with the latest Tapestry releases. Also, that application is
> very
> small with only a few concepts being covered.
>
> I have used other frameworks (specifically ZK) that are very well
> documented
> and easy to use, come with a comprehensive set of examples that is easy to
> download and setup. Even Wicket has a good demo application (as war file
> with sources) that ships with every release that just works.
>
> It would be really helpful if every release of Tapestry shipped with a
> standard demo project (like the Spring Petshop or ZK Explorer or Seam Hotel
> Reservation) with all the best practices illustrated (Spring/Hibernate
> integration etc).
>
> Without a book, and no working example code that can easily be installed
> (without maven), it is very hard to learn the framework (however simple the
> framework might be).
>
>
>
>
>
>
> Juan E. Maya wrote:
> >
> > did u follow the tapestry quickstart in
> > http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> > could get easier than this. U can even run it inside eclipse if u have
> > the m2 plugin for maven.
> >
> > i do agree with u that the documentation could be better, however,
> > reading your message somebody could believe that starting a new
> > tapestry project is extremely difficult and it's totally the contrary.
> >
> > On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com> wrote:
> >> I've been using T4/4.1 for several years and have been quite pleased
> with
> >> it. I've been using it with Hibernate, and while not perfect, it's
> worked
> >> pretty well. We've found it much faster to embed a web browser in our
> >> main
> >> app and do editing, queries and the like via Tapestry than writing
> native
> >> code.
> >>
> >> I have a new project to replace our aging billing system. I figured this
> >> would be a great way to learn T5. So, I'm migrating me, not an app. :-)
> >>
> >> I was pondering posting this, but this thread sort of pushed me over the
> >> top. Note that I don't disagree with anything Howard said. However, this
> >> almost became "Why I almost dumped Tapestry entirely."
> >>
> >> I'm writing this in order to solicit feedback and maybe help others.
> I've
> >> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time
> >> time,
> >> and I'm very productive developing use them (and T4.1) I think this is a
> >> pretty common development environment.
> >>
> >> To get started in T5 for a fresh new app, my first thought was to follow
> >> the
> >> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
> >>
> >> Chapter 2 just plain didn't work for me. I think part of it is due to
> >> Maven
> >> generally being extremely fragile and working less than half of the
> time.
> >> However, even after working around that, you can't just import the
> >> project
> >> into Eclipse. At least not under Eclipse 3.4.2.
> >>
> >> No problem, I thought. Maven is annoying anyway. I'll just create a
> >> Dynamic
> >> Web project (like I do for T4.1) and download the T5.1 binary
> >> distribution.
> >> That's even worse. It comes with no README listing dependencies or
> >> anything
> >> useful, and includes tons of libraries that don't appear to be even
> >> needed.
> >> Tapestry failed to start up during initialization. Why have a binary
> >> distro
> >> that doesn't work?
> >>
> >> Back to Maven. After some googling, I found this article:
> >>
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven)
>  Shouldn't
> >> this be included in the tutorial? Sadly, the tutorial is extremely
> basic,
> >> but at least it works. (And is the only way I've found to actually
> create
> >> a
> >> new project in Eclipse to date.)
> >>
> >> Next, I tried Tapestry Jumpstart. After hours of configuration and
> random
> >> errors (using Tomcat), it worked. However, it's so fragile and klugy
> that
> >> I
> >> just can't see using it in production. I don't care about OpenEJB. I
> want
> >> just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions
> >> eliminates many of the developer productivity benefits of T5 in the
> first
> >> place. One thing I liked about T4 was that I could deploy a WAR to a
> >> stock
> >> Tomcat install, and it would just work. That won't happen with
> Jumpstart.
> >> Plus. it if takes 3 hours to just get a working developer environment,
> >> why
> >> even bother?
> >>
> >> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly,
> >> AppFuse's T4 support is now broken due to a dependancy on tapestry-flash
> >> that appears to be missing and following the instructions on the AppFuse
> >> Tapestry 5 page doesn't work anymore either, resulting in tons of
> missing
> >> resources.
> >>
> >> So, since T5 doesn't appear to provide much in the way of authentication
> >> /
> >> security (a very basic requirement for almost all webapps), I started
> >> down
> >> the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I
> >> managed to get it working and then upgraded to tapestry-spring-security
> >> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven
> >> for
> >> not updating the packages when I switched to the snapshot, too. I had to
> >> delete the "nu" directory in my ~/.m2 directory. One more reason Maven
> >> blows. It just doesn't do what you want.)
> >>
> >> I'd love to see more people use Tapestry, but after attempting a new
> >> project, I'd feel embarrassed asking people to give Tapestry a look at
> >> this
> >> point. Heck, I'm thinking maybe sticking with T4.1 is the way to go,
> >> despite
> >> all the benefits of T5. But, I really do want to start in on T5 since
> >> I've
> >> loved using T4 for the last few years, and it does seem to be a step
> >> forward.
> >>
> >> I think its common to want to just get something working in order to get
> >> a
> >> feel for the framework. Doing so in Tapestry, at least for me, has been
> a
> >> waste of two days. I finally, on the third day, I have something that
> >> appears to allow the tutorial to work with basic security. I'm not sure
> >> if
> >> others have similar problems and just gave up without comment, making
> >> other
> >> frameworks seem more popular?
> >>
> >> Norman Franke
> >> Answering Service for Directors, Inc.
> >> www.myasd.com
> >>
> >>
> >>
> >> On Jun 16, 2009, at 7:20 PM, Howard wrote:
> >>
> >>> I recently had an e-mail exchange with a Tapestry user; after
> >>> congratulating me on creating Tapestry, he went on with the following
> >>> observation on his organization: The company I work at unfortunately
> >>> chose JSF for their big app. The reason was that Tapestry was "brittle"
> >>> in the sense that, if one developer breaks something, on a page or a
> >>> service, very often the whole site won't come up because the initial
> >>> registry startup will fail. Or for example, if page A has a pagelink to
> >>> page B, and page B is broken, then page A won't render. While I agree
> >>> that we shouldn't ship unless the whole app is working, this is a
> >>> thousands of pages big app with hundreds of mediocre (as in likely to
> >>> break things) developers. They'd rather have 80% of the thing working
> >>> than nothing at all. I never thought of this for my own projects, and
> >>> haven't had the time to examine the truth of their claims. What's your
> >>> take?
> >>> I provided the following response:
> >>> Early failures are absolutely, 100%, the only path towards code
> >>> quality. You may have heard the phrase "no broken windows" (see "The
> >>> Tipping Point" by Malcom Gladwell for more details) but the short form
> >>> is that when errors go uncorrected (whether they are broken windows in
> >>> an abandoned building, or broken code in an application) they tend to
> >>> multiply quite rapidly.
> >>> The things that will "break" a link from page A to page B are
> >>> substantial problems such as invalid templates, references to unknown
> >>> properties or components, or compile errors in the page B class ...
> >>> things that no other developer should ever see when page B's developer
> >>> is working and checking in code. That is, problems that should never be
> >>> checked into trunk, but instead kept in a local workspace or a private
> >>> branch.
> >>> An organization that thinks that fail early is a problem is an
> >>> organization that isn't prepared to develop a large application in any
> >>> technology. The image I'm getting is one where there is no build
> >>> server, no continuous integration, at best CVS for source code
> >>> management (or possibly one of those "shared directory"
> >>> monstrosities) .... i.e., a chaotic environment where errors are
> >>> allowed to be checked in to the trunk and can go unnoticed for some
> >>> time.
> >>> The solution to coding errors in pages or components is not to wait
> >>> until your testers (or end users) find the bugs, but to identify and
> >>> fix the bugs early. That's called "engineering discipline" and the
> >>> reality is that even self-professed "mediocre" developers can do it.
> >>> Tapestry helps because it fails early and has great exception reporting
> >>> to guide you right the problem so that you can fix it.
> >>> Another factor here is enforced helplessness. If only Fred understands
> >>> page B and he's out when it's broken, then all development stops
> >>> waiting for Fred to get back. I hit this problem myself, years ago
> >>> working on a large Struts application (those words give me the heebie
> >>> jeebies now!). We had lots of code, a fragile and slow build process,
> >>> and many little code "fiefdoms". I spent too much wasted time twiddling
> >>> my thumbs.
> >>> Nobody should "own the code"; if page B is is broken, Julie (who
> >>> normally develops page A) should be free to fix it. Julie will need to
> >>> understand the page B code well enough to fix it, but also you need an
> >>> overall environment with shared source, no repository locks (that is,
> >>> nothing that says "Only Fred can change this file"), and no management
> >>> PHB's getting in the way. Pair programming is the best way for Fred and
> >>> Julie to share knowledge so that they can understand each other's code.
> >>> Even if pairing occurs only part time, it's very effective at knowledge
> >>> transfer as well as ordinary coding.
> >>> The idea that "mediocre" developers should use JSF as it is more
> >>> tolerant of errors is absurd! Tapestry 5 is designed to improve
> >>> productivity for all developers, by streamlining, simplifying, being
> >>> smart and being concise ... not to mention live class reloading and
> >>> best-of-breed exception reporting, which makes it fast to identify and
> >>> fix those errors.
> >>> If your doctor tells you to eat less red meat, that doesn't mean you
> >>> should switch to a diet of fried chicken three meals a day! Likewise,
> >>> if you have concerns with code quality from your developers, you should
> >>> not switch to a less agile, more code-intensive, less supportive
> >>> development model and hope to catch all the bugs in QA. Sweeping
> >>> problems under the rug is never a winning strategy.
> >>> Coming down off my soap box, I should also add that Tapestry 5.1 works
> >>> a little bit differently than 5.0 in this respect, so it does (in fact)
> >>> defer more of the page loading and validation until a link is actually
> >>> clicked. This is more for performance reasons than to shield developers
> >>> from application problems. Even in 5.0, the loading and validation was
> >>> the "reach" from page A to pages explicitly referenced (usually via
> >>> PageLink during the rendering of page A), so it's a highly unlikely
> >>> case that a single error in a 1000 page application will keep the
> >>> application from starting up, unless the start page of the application
> >>> links to all 999 other pages.
> >>> Re-reading the above post I can't emphasize enough: you can't ignore
> >>> quality problems. Quality problems lead to development failures,
> >>> schedule slips, missing functionality, low morale and high turnover.
> >>> Saying "we don't have time to fix the quality problem first" is to
> >>> ignore the the second law of Thermodynamics. You are expecting a
> >>> miracle, literally writing it into your project plan.
> >>> Formos addresses this issue two ways: First, we use Scrum and deliver
> >>> on (typically) 4 week cycles. Thus we set real deadlines and have a
> >>> constant check on quality (we're providing working code constantly). We
> >>> don't even try to predict what we'll be doing six months or two years
> >>> from now, we just deliver a steady, manageable stream of software.
> >>> Secondly, Formos uses Tapestry because of all the reasons that the
> >>> anonymous developer's organization rejected it, and for many, many more
> >>> reasons besides.
> >>>
> >>> --
> >>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> >>
> >>
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org
> >
> >
> >
>
> --
> View this message in context:
> http://n2.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp3089605p3095973.html
> Sent from the Tapestry Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

Re: [Tapestry Central] Why chose Tapestry?

[Sparqle <ds...@gmail.com>]

I agree with Juan. This is the biggest barrier to Tapestry adoption. 
Most people I know who are working even for big corporations are not used to
Maven. In fact I know at least 100 developers from various companies in our
area and nobody uses Maven. Most people want a dynamic web project in
eclipse with the ability to export/import the application from/into eclipse
as a war file.

I have wasted a lot of time myself with Tapestry5 already. Most of the
articles and examples either don't work or are incomplete. I think Tapestry5
is probably very innovative, easy and fast, but getting the development
environment setup right is very tough (without maven). The other problem is
the understanding the best practices for Spring, Hibernate integration etc.
The Jumpstart application tries to do this. 

It would be nice if the Jumpstart application was available as a war file
(with sources) which could then be imported as a regular Dynamic web project
in Eclipse. But to get Jumpstart to work on Eclipse is a marathon activity
with thousands of steps. I gave up. How about 1 step: simple war file with
all the sources that is easy to import into Eclipse? 

The Tapestry4NonBelievers site does this, but their war file is not
compatible with the latest Tapestry releases. Also, that application is very
small with only a few concepts being covered.

I have used other frameworks (specifically ZK) that are very well documented
and easy to use, come with a comprehensive set of examples that is easy to
download and setup. Even Wicket has a good demo application (as war file
with sources) that ships with every release that just works.

It would be really helpful if every release of Tapestry shipped with a
standard demo project (like the Spring Petshop or ZK Explorer or Seam Hotel
Reservation) with all the best practices illustrated (Spring/Hibernate
integration etc). 

Without a book, and no working example code that can easily be installed
(without maven), it is very hard to learn the framework (however simple the
framework might be).






Juan E. Maya wrote:
> 
> did u follow the tapestry quickstart in
> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> could get easier than this. U can even run it inside eclipse if u have
> the m2 plugin for maven.
> 
> i do agree with u that the documentation could be better, however,
> reading your message somebody could believe that starting a new
> tapestry project is extremely difficult and it's totally the contrary.
> 
> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com> wrote:
>> I've been using T4/4.1 for several years and have been quite pleased with
>> it. I've been using it with Hibernate, and while not perfect, it's worked
>> pretty well. We've found it much faster to embed a web browser in our
>> main
>> app and do editing, queries and the like via Tapestry than writing native
>> code.
>>
>> I have a new project to replace our aging billing system. I figured this
>> would be a great way to learn T5. So, I'm migrating me, not an app. :-)
>>
>> I was pondering posting this, but this thread sort of pushed me over the
>> top. Note that I don't disagree with anything Howard said. However, this
>> almost became "Why I almost dumped Tapestry entirely."
>>
>> I'm writing this in order to solicit feedback and maybe help others. I've
>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time
>> time,
>> and I'm very productive developing use them (and T4.1) I think this is a
>> pretty common development environment.
>>
>> To get started in T5 for a fresh new app, my first thought was to follow
>> the
>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>
>> Chapter 2 just plain didn't work for me. I think part of it is due to
>> Maven
>> generally being extremely fragile and working less than half of the time.
>> However, even after working around that, you can't just import the
>> project
>> into Eclipse. At least not under Eclipse 3.4.2.
>>
>> No problem, I thought. Maven is annoying anyway. I'll just create a
>> Dynamic
>> Web project (like I do for T4.1) and download the T5.1 binary
>> distribution.
>> That's even worse. It comes with no README listing dependencies or
>> anything
>> useful, and includes tons of libraries that don't appear to be even
>> needed.
>> Tapestry failed to start up during initialization. Why have a binary
>> distro
>> that doesn't work?
>>
>> Back to Maven. After some googling, I found this article:
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) Shouldn't
>> this be included in the tutorial? Sadly, the tutorial is extremely basic,
>> but at least it works. (And is the only way I've found to actually create
>> a
>> new project in Eclipse to date.)
>>
>> Next, I tried Tapestry Jumpstart. After hours of configuration and random
>> errors (using Tomcat), it worked. However, it's so fragile and klugy that
>> I
>> just can't see using it in production. I don't care about OpenEJB. I want
>> just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions
>> eliminates many of the developer productivity benefits of T5 in the first
>> place. One thing I liked about T4 was that I could deploy a WAR to a
>> stock
>> Tomcat install, and it would just work. That won't happen with Jumpstart.
>> Plus. it if takes 3 hours to just get a working developer environment,
>> why
>> even bother?
>>
>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly,
>> AppFuse's T4 support is now broken due to a dependancy on tapestry-flash
>> that appears to be missing and following the instructions on the AppFuse
>> Tapestry 5 page doesn't work anymore either, resulting in tons of missing
>> resources.
>>
>> So, since T5 doesn't appear to provide much in the way of authentication
>> /
>> security (a very basic requirement for almost all webapps), I started
>> down
>> the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I
>> managed to get it working and then upgraded to tapestry-spring-security
>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven
>> for
>> not updating the packages when I switched to the snapshot, too. I had to
>> delete the "nu" directory in my ~/.m2 directory. One more reason Maven
>> blows. It just doesn't do what you want.)
>>
>> I'd love to see more people use Tapestry, but after attempting a new
>> project, I'd feel embarrassed asking people to give Tapestry a look at
>> this
>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to go,
>> despite
>> all the benefits of T5. But, I really do want to start in on T5 since
>> I've
>> loved using T4 for the last few years, and it does seem to be a step
>> forward.
>>
>> I think its common to want to just get something working in order to get
>> a
>> feel for the framework. Doing so in Tapestry, at least for me, has been a
>> waste of two days. I finally, on the third day, I have something that
>> appears to allow the tutorial to work with basic security. I'm not sure
>> if
>> others have similar problems and just gave up without comment, making
>> other
>> frameworks seem more popular?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>
>>> I recently had an e-mail exchange with a Tapestry user; after
>>> congratulating me on creating Tapestry, he went on with the following
>>> observation on his organization: The company I work at unfortunately
>>> chose JSF for their big app. The reason was that Tapestry was "brittle"
>>> in the sense that, if one developer breaks something, on a page or a
>>> service, very often the whole site won't come up because the initial
>>> registry startup will fail. Or for example, if page A has a pagelink to
>>> page B, and page B is broken, then page A won't render. While I agree
>>> that we shouldn't ship unless the whole app is working, this is a
>>> thousands of pages big app with hundreds of mediocre (as in likely to
>>> break things) developers. They'd rather have 80% of the thing working
>>> than nothing at all. I never thought of this for my own projects, and
>>> haven't had the time to examine the truth of their claims. What's your
>>> take?
>>> I provided the following response:
>>> Early failures are absolutely, 100%, the only path towards code
>>> quality. You may have heard the phrase "no broken windows" (see "The
>>> Tipping Point" by Malcom Gladwell for more details) but the short form
>>> is that when errors go uncorrected (whether they are broken windows in
>>> an abandoned building, or broken code in an application) they tend to
>>> multiply quite rapidly.
>>> The things that will "break" a link from page A to page B are
>>> substantial problems such as invalid templates, references to unknown
>>> properties or components, or compile errors in the page B class ...
>>> things that no other developer should ever see when page B's developer
>>> is working and checking in code. That is, problems that should never be
>>> checked into trunk, but instead kept in a local workspace or a private
>>> branch.
>>> An organization that thinks that fail early is a problem is an
>>> organization that isn't prepared to develop a large application in any
>>> technology. The image I'm getting is one where there is no build
>>> server, no continuous integration, at best CVS for source code
>>> management (or possibly one of those "shared directory"
>>> monstrosities) .... i.e., a chaotic environment where errors are
>>> allowed to be checked in to the trunk and can go unnoticed for some
>>> time.
>>> The solution to coding errors in pages or components is not to wait
>>> until your testers (or end users) find the bugs, but to identify and
>>> fix the bugs early. That's called "engineering discipline" and the
>>> reality is that even self-professed "mediocre" developers can do it.
>>> Tapestry helps because it fails early and has great exception reporting
>>> to guide you right the problem so that you can fix it.
>>> Another factor here is enforced helplessness. If only Fred understands
>>> page B and he's out when it's broken, then all development stops
>>> waiting for Fred to get back. I hit this problem myself, years ago
>>> working on a large Struts application (those words give me the heebie
>>> jeebies now!). We had lots of code, a fragile and slow build process,
>>> and many little code "fiefdoms". I spent too much wasted time twiddling
>>> my thumbs.
>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>> normally develops page A) should be free to fix it. Julie will need to
>>> understand the page B code well enough to fix it, but also you need an
>>> overall environment with shared source, no repository locks (that is,
>>> nothing that says "Only Fred can change this file"), and no management
>>> PHB's getting in the way. Pair programming is the best way for Fred and
>>> Julie to share knowledge so that they can understand each other's code.
>>> Even if pairing occurs only part time, it's very effective at knowledge
>>> transfer as well as ordinary coding.
>>> The idea that "mediocre" developers should use JSF as it is more
>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>> productivity for all developers, by streamlining, simplifying, being
>>> smart and being concise ... not to mention live class reloading and
>>> best-of-breed exception reporting, which makes it fast to identify and
>>> fix those errors.
>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>> should switch to a diet of fried chicken three meals a day! Likewise,
>>> if you have concerns with code quality from your developers, you should
>>> not switch to a less agile, more code-intensive, less supportive
>>> development model and hope to catch all the bugs in QA. Sweeping
>>> problems under the rug is never a winning strategy.
>>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>>> a little bit differently than 5.0 in this respect, so it does (in fact)
>>> defer more of the page loading and validation until a link is actually
>>> clicked. This is more for performance reasons than to shield developers
>>> from application problems. Even in 5.0, the loading and validation was
>>> the "reach" from page A to pages explicitly referenced (usually via
>>> PageLink during the rendering of page A), so it's a highly unlikely
>>> case that a single error in a 1000 page application will keep the
>>> application from starting up, unless the start page of the application
>>> links to all 999 other pages.
>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>> quality problems. Quality problems lead to development failures,
>>> schedule slips, missing functionality, low morale and high turnover.
>>> Saying "we don't have time to fix the quality problem first" is to
>>> ignore the the second law of Thermodynamics. You are expecting a
>>> miracle, literally writing it into your project plan.
>>> Formos addresses this issue two ways: First, we use Scrum and deliver
>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>> constant check on quality (we're providing working code constantly). We
>>> don't even try to predict what we'll be doing six months or two years
>>> from now, we just deliver a steady, manageable stream of software.
>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>> anonymous developer's organization rejected it, and for many, many more
>>> reasons besides.
>>>
>>> --
>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
> 
> 
> 

-- 
View this message in context: http://n2.nabble.com/-Tapestry-Central--Why-chose-Tapestry--tp3089605p3095973.html
Sent from the Tapestry Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Brandon Atkinson <br...@gmail.com>]

Maven by itself is not that big of a deal.  Almost any system using
declarative builds and dependency management would have worked to improve
Java builds.I've felt frustrated by Maven too. I've frequently complained
about the quality of some of the plugins... but...

In the shop I work in, historically every developer was a project manager,
developer, and 'salesman'.  This led to many projects, most using Ant to
build.  Each Ant build would perform fundamentally similar builds, but each
project's build code was different.  You couldn't efficiently work on
another developers project without reading the Ant build first, and you
certainly couldn't expect any certain goals to be defined.  This boils down
to a lack of developer discipline, which is what the Maven lifecycles
enforce.  Moving to maven made our builds consistent.  It took a bunch of
rogue coders and forced them to produce predictable builds; a HUGE
improvement.

That said, this isn't a consulting shop that creates stand alone
applications.  We must maintain anything we create, so creation efficiency
is less of a priority than long term maintainability.  If I were a
consultant and a customer said 'screw the long term' I would whip off an Ant
build.  It can be faster to create.  It also may secure my status as the
sole consultant, if I make my build really wacky ;-D

The real benefit of creating regular builds is that it gives you the ability
to use continuous integration and artifact management.  If you haven't set
up all the infrastructure and tried it, it may seem unneeded.  For our shop,
it has improved things greatly.  In the past, there had been several
occasions where a developer left the company without checking in source code
that was in production.  The developer's code worked for long enough for
their machine to be reformatted and given to someone else, then a bug
surfaced.  Oops... lost source code, with no developer.  Using a continuous
integration server with scheduled and automated deployments prevents any
project from going live without being in source control.  Problem gone.

I do understand that not everyone has these sorts of problems.  For those
that do, maven/continuum/archiva are great.




On Thu, Jun 18, 2009 at 4:37 AM, Joel Halbert <jo...@su3analytics.com> wrote:

> I'm still not convinced that using Maven is a good thing.
> It's fine for those people that use it day to day already, but for those
> people who have no need/interest in picking up another framework and who
> just
> want to get on with using Tapestry its a real bug bear.
>
> I've always just downloaded the binaries for whatever project I'm using and
> dropped them into my project. I very rarely have versioning issues (if
> every
> at all in fact). I'd go so far as to say that this is preferable - you know
> exactly what code your using, and why, because you've put it there yourself
> rather than having some opaque system under the hood doing it for you. This
> would seem to give you a greater degree of control over whats in your
> environment - important when it comes to deploying.
>
> On Wednesday 17 June 2009 22:15:23 Norman Franke wrote:
> > I did, and that worked using jetty on the command line. Eventually,
> > following the other instructions, I was able to even get that working
> > in Eclipse. However, it is very basic: no hibernate, no security/
> > authentication.
> >
> > I started following the instructions in the tutorial, which do not work.
> >
> > Norman Franke
> > Answering Service for Directors, Inc.
> > www.myasd.com
> >
> > On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:
> > > did u follow the tapestry quickstart in
> > > http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> > > could get easier than this. U can even run it inside eclipse if u have
> > > the m2 plugin for maven.
> > >
> > > i do agree with u that the documentation could be better, however,
> > > reading your message somebody could believe that starting a new
> > > tapestry project is extremely difficult and it's totally the contrary.
> > >
> > > On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com>
> > >
> > > wrote:
> > >> I've been using T4/4.1 for several years and have been quite
> > >> pleased with
> > >> it. I've been using it with Hibernate, and while not perfect, it's
> > >> worked
> > >> pretty well. We've found it much faster to embed a web browser in
> > >> our main
> > >> app and do editing, queries and the like via Tapestry than writing
> > >> native
> > >> code.
> > >>
> > >> I have a new project to replace our aging billing system. I figured
> > >> this
> > >> would be a great way to learn T5. So, I'm migrating me, not an
> > >> app. :-)
> > >>
> > >> I was pondering posting this, but this thread sort of pushed me
> > >> over the
> > >> top. Note that I don't disagree with anything Howard said. However,
> > >> this
> > >> almost became "Why I almost dumped Tapestry entirely."
> > >>
> > >> I'm writing this in order to solicit feedback and maybe help
> > >> others. I've
> > >> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
> > >> time time,
> > >> and I'm very productive developing use them (and T4.1) I think this
> > >> is a
> > >> pretty common development environment.
> > >>
> > >> To get started in T5 for a fresh new app, my first thought was to
> > >> follow the
> > >> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
> > >>
> > >> Chapter 2 just plain didn't work for me. I think part of it is due
> > >> to Maven
> > >> generally being extremely fragile and working less than half of the
> > >> time.
> > >> However, even after working around that, you can't just import the
> > >> project
> > >> into Eclipse. At least not under Eclipse 3.4.2.
> > >>
> > >> No problem, I thought. Maven is annoying anyway. I'll just create a
> > >> Dynamic
> > >> Web project (like I do for T4.1) and download the T5.1 binary
> > >> distribution.
> > >> That's even worse. It comes with no README listing dependencies or
> > >> anything
> > >> useful, and includes tons of libraries that don't appear to be even
> > >> needed.
> > >> Tapestry failed to start up during initialization. Why have a
> > >> binary distro
> > >> that doesn't work?
> > >>
> > >> Back to Maven. After some googling, I found this article:
> > >>
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mave
> > >>n) Shouldn't
> > >> this be included in the tutorial? Sadly, the tutorial is extremely
> > >> basic,
> > >> but at least it works. (And is the only way I've found to actually
> > >> create a
> > >> new project in Eclipse to date.)
> > >>
> > >> Next, I tried Tapestry Jumpstart. After hours of configuration and
> > >> random
> > >> errors (using Tomcat), it worked. However, it's so fragile and
> > >> klugy that I
> > >> just can't see using it in production. I don't care about OpenEJB.
> > >> I want
> > >> just plain T5.1 and Hibernate. Plus running in a remote tomcat
> > >> sessions
> > >> eliminates many of the developer productivity benefits of T5 in the
> > >> first
> > >> place. One thing I liked about T4 was that I could deploy a WAR to
> > >> a stock
> > >> Tomcat install, and it would just work. That won't happen with
> > >> Jumpstart.
> > >> Plus. it if takes 3 hours to just get a working developer
> > >> environment, why
> > >> even bother?
> > >>
> > >> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
> > >> Sadly,
> > >> AppFuse's T4 support is now broken due to a dependancy on tapestry-
> > >> flash
> > >> that appears to be missing and following the instructions on the
> > >> AppFuse
> > >> Tapestry 5 page doesn't work anymore either, resulting in tons of
> > >> missing
> > >> resources.
> > >>
> > >> So, since T5 doesn't appear to provide much in the way of
> > >> authentication /
> > >> security (a very basic requirement for almost all webapps), I
> > >> started down
> > >> the tapestry5-acegi approach. Of course, that doesn't work with
> > >> T5.1. I
> > >> managed to get it working and then upgraded to tapestry-spring-
> > >> security
> > >> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to
> > >> maven for
> > >> not updating the packages when I switched to the snapshot, too. I
> > >> had to
> > >> delete the "nu" directory in my ~/.m2 directory. One more reason
> > >> Maven
> > >> blows. It just doesn't do what you want.)
> > >>
> > >> I'd love to see more people use Tapestry, but after attempting a new
> > >> project, I'd feel embarrassed asking people to give Tapestry a look
> > >> at this
> > >> point. Heck, I'm thinking maybe sticking with T4.1 is the way to
> > >> go, despite
> > >> all the benefits of T5. But, I really do want to start in on T5
> > >> since I've
> > >> loved using T4 for the last few years, and it does seem to be a step
> > >> forward.
> > >>
> > >> I think its common to want to just get something working in order
> > >> to get a
> > >> feel for the framework. Doing so in Tapestry, at least for me, has
> > >> been a
> > >> waste of two days. I finally, on the third day, I have something that
> > >> appears to allow the tutorial to work with basic security. I'm not
> > >> sure if
> > >> others have similar problems and just gave up without comment,
> > >> making other
> > >> frameworks seem more popular?
> > >>
> > >> Norman Franke
> > >> Answering Service for Directors, Inc.
> > >> www.myasd.com
> > >>
> > >> On Jun 16, 2009, at 7:20 PM, Howard wrote:
> > >>> I recently had an e-mail exchange with a Tapestry user; after
> > >>> congratulating me on creating Tapestry, he went on with the
> > >>> following
> > >>> observation on his organization: The company I work at unfortunately
> > >>> chose JSF for their big app. The reason was that Tapestry was
> > >>> "brittle"
> > >>> in the sense that, if one developer breaks something, on a page or a
> > >>> service, very often the whole site won't come up because the initial
> > >>> registry startup will fail. Or for example, if page A has a
> > >>> pagelink to
> > >>> page B, and page B is broken, then page A won't render. While I
> > >>> agree
> > >>> that we shouldn't ship unless the whole app is working, this is a
> > >>> thousands of pages big app with hundreds of mediocre (as in likely
> > >>> to
> > >>> break things) developers. They'd rather have 80% of the thing
> > >>> working
> > >>> than nothing at all. I never thought of this for my own projects,
> > >>> and
> > >>> haven't had the time to examine the truth of their claims. What's
> > >>> your
> > >>> take?
> > >>> I provided the following response:
> > >>> Early failures are absolutely, 100%, the only path towards code
> > >>> quality. You may have heard the phrase "no broken windows" (see "The
> > >>> Tipping Point" by Malcom Gladwell for more details) but the short
> > >>> form
> > >>> is that when errors go uncorrected (whether they are broken
> > >>> windows in
> > >>> an abandoned building, or broken code in an application) they tend
> > >>> to
> > >>> multiply quite rapidly.
> > >>> The things that will "break" a link from page A to page B are
> > >>> substantial problems such as invalid templates, references to
> > >>> unknown
> > >>> properties or components, or compile errors in the page B class ...
> > >>> things that no other developer should ever see when page B's
> > >>> developer
> > >>> is working and checking in code. That is, problems that should
> > >>> never be
> > >>> checked into trunk, but instead kept in a local workspace or a
> > >>> private
> > >>> branch.
> > >>> An organization that thinks that fail early is a problem is an
> > >>> organization that isn't prepared to develop a large application in
> > >>> any
> > >>> technology. The image I'm getting is one where there is no build
> > >>> server, no continuous integration, at best CVS for source code
> > >>> management (or possibly one of those "shared directory"
> > >>> monstrosities) .... i.e., a chaotic environment where errors are
> > >>> allowed to be checked in to the trunk and can go unnoticed for some
> > >>> time.
> > >>> The solution to coding errors in pages or components is not to wait
> > >>> until your testers (or end users) find the bugs, but to identify and
> > >>> fix the bugs early. That's called "engineering discipline" and the
> > >>> reality is that even self-professed "mediocre" developers can do it.
> > >>> Tapestry helps because it fails early and has great exception
> > >>> reporting
> > >>> to guide you right the problem so that you can fix it.
> > >>> Another factor here is enforced helplessness. If only Fred
> > >>> understands
> > >>> page B and he's out when it's broken, then all development stops
> > >>> waiting for Fred to get back. I hit this problem myself, years ago
> > >>> working on a large Struts application (those words give me the
> > >>> heebie
> > >>> jeebies now!). We had lots of code, a fragile and slow build
> > >>> process,
> > >>> and many little code "fiefdoms". I spent too much wasted time
> > >>> twiddling
> > >>> my thumbs.
> > >>> Nobody should "own the code"; if page B is is broken, Julie (who
> > >>> normally develops page A) should be free to fix it. Julie will
> > >>> need to
> > >>> understand the page B code well enough to fix it, but also you
> > >>> need an
> > >>> overall environment with shared source, no repository locks (that
> > >>> is,
> > >>> nothing that says "Only Fred can change this file"), and no
> > >>> management
> > >>> PHB's getting in the way. Pair programming is the best way for
> > >>> Fred and
> > >>> Julie to share knowledge so that they can understand each other's
> > >>> code.
> > >>> Even if pairing occurs only part time, it's very effective at
> > >>> knowledge
> > >>> transfer as well as ordinary coding.
> > >>> The idea that "mediocre" developers should use JSF as it is more
> > >>> tolerant of errors is absurd! Tapestry 5 is designed to improve
> > >>> productivity for all developers, by streamlining, simplifying, being
> > >>> smart and being concise ... not to mention live class reloading and
> > >>> best-of-breed exception reporting, which makes it fast to identify
> > >>> and
> > >>> fix those errors.
> > >>> If your doctor tells you to eat less red meat, that doesn't mean you
> > >>> should switch to a diet of fried chicken three meals a day!
> > >>> Likewise,
> > >>> if you have concerns with code quality from your developers, you
> > >>> should
> > >>> not switch to a less agile, more code-intensive, less supportive
> > >>> development model and hope to catch all the bugs in QA. Sweeping
> > >>> problems under the rug is never a winning strategy.
> > >>> Coming down off my soap box, I should also add that Tapestry 5.1
> > >>> works
> > >>> a little bit differently than 5.0 in this respect, so it does (in
> > >>> fact)
> > >>> defer more of the page loading and validation until a link is
> > >>> actually
> > >>> clicked. This is more for performance reasons than to shield
> > >>> developers
> > >>> from application problems. Even in 5.0, the loading and validation
> > >>> was
> > >>> the "reach" from page A to pages explicitly referenced (usually via
> > >>> PageLink during the rendering of page A), so it's a highly unlikely
> > >>> case that a single error in a 1000 page application will keep the
> > >>> application from starting up, unless the start page of the
> > >>> application
> > >>> links to all 999 other pages.
> > >>> Re-reading the above post I can't emphasize enough: you can't ignore
> > >>> quality problems. Quality problems lead to development failures,
> > >>> schedule slips, missing functionality, low morale and high turnover.
> > >>> Saying "we don't have time to fix the quality problem first" is to
> > >>> ignore the the second law of Thermodynamics. You are expecting a
> > >>> miracle, literally writing it into your project plan.
> > >>> Formos addresses this issue two ways: First, we use Scrum and
> > >>> deliver
> > >>> on (typically) 4 week cycles. Thus we set real deadlines and have a
> > >>> constant check on quality (we're providing working code
> > >>> constantly). We
> > >>> don't even try to predict what we'll be doing six months or two
> > >>> years
> > >>> from now, we just deliver a steady, manageable stream of software.
> > >>> Secondly, Formos uses Tapestry because of all the reasons that the
> > >>> anonymous developer's organization rejected it, and for many, many
> > >>> more
> > >>> reasons besides.
> > >>>
> > >>> --
> > >>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > > For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> --
> Joel Halbert
> 020 3051 8637
> 075 2501 0825
> joel@su3analytics.com
> www.su3analytics.com
> www.storequery.com
> SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>
>

RE: [Tapestry Central] Why chose Tapestry?

["Newham, Cameron" <ca...@bl.uk>]

I have found Maven is great for starting a T5 project, but if you aren't
careful later on then it can become a nightmarish hell.

Having to remove and rebuild the repository a tool has created because
it has gone and messed it up doth not a good tool make.


-----Original Message-----
From: Joel Halbert [mailto:joel@su3analytics.com] 
Sent: 18 June 2009 09:38
To: users@tapestry.apache.org
Subject: Re: [Tapestry Central] Why chose Tapestry?

I'm still not convinced that using Maven is a good thing.
It's fine for those people that use it day to day already, but for those

people who have no need/interest in picking up another framework and who
just 
want to get on with using Tapestry its a real bug bear.

...

**************************************************************************
 
Experience the British Library online at www.bl.uk
 
The British Library's new interactive Annual Report and Accounts 2007/08 : www.bl.uk/knowledge
 
Help the British Library conserve the world's knowledge. Adopt a Book. www.bl.uk/adoptabook
 
The Library's St Pancras site is WiFi - enabled
 
*************************************************************************
 
The information contained in this e-mail is confidential and may be legally privileged. It is intended for the addressee(s) only. If you are not the intended recipient, please delete this e-mail and notify the postmaster@bl.uk : The contents of this e-mail must not be disclosed or copied without the sender's consent. 
 
The statements and opinions expressed in this message are those of the author and do not necessarily reflect those of the British Library. The British Library does not take any responsibility for the views of the author. 
 
*************************************************************************

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Kalle Korhonen <ka...@gmail.com>]

This is a funny thread. Maybe it'd be better to spend all this energy
in learning the tools rather than complaining. Whatever the tool is,
understand that the dependencies are yours to manage. The truth is
that today's applications written in Java are so complex and comprised
of so many little libraries that maintaining it all manually is
painstakingly slow and error-prone. I take automatic transitive
dependency management any day even though it sometimes means I need to
resort to long list of excludes and at times explicitly *decide* and
declare which version of a particular library I actually want to use
in my application in case of conflicts. In return, I get an
environment that is easy to maintain by myself only and other people
in my group don't have to go through the same trouble of setting
everything up one library at a time. My designers are happily running
mvn jetty:run and editing the templates on-the-fly with their little
Dreamweavers, BlueFishes and Notepads or whatever the heck they want
to use without ever having to know that such a thing as compilation or
dependency resolution is happening all automatically for them.

Kalle


On Thu, Jun 18, 2009 at 9:37 AM, Norman Franke<no...@myasd.com> wrote:
> That's precisely what I was used to. I had to learn much more about Maven
> that I wanted to just get started with a trivial T5 app until I found the
> secret instructions on a blog post from Howard. I haven't even tried
> deploying anything non-trivial yet.
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jun 18, 2009, at 4:37 AM, Joel Halbert wrote:
>
>> I'm still not convinced that using Maven is a good thing.
>> It's fine for those people that use it day to day already, but for those
>> people who have no need/interest in picking up another framework and who
>> just
>> want to get on with using Tapestry its a real bug bear.
>>
>> I've always just downloaded the binaries for whatever project I'm using
>> and
>> dropped them into my project. I very rarely have versioning issues (if
>> every
>> at all in fact). I'd go so far as to say that this is preferable - you
>> know
>> exactly what code your using, and why, because you've put it there
>> yourself
>> rather than having some opaque system under the hood doing it for you.
>> This
>> would seem to give you a greater degree of control over whats in your
>> environment - important when it comes to deploying.
>>
>> On Wednesday 17 June 2009 22:15:23 Norman Franke wrote:
>>>
>>> I did, and that worked using jetty on the command line. Eventually,
>>> following the other instructions, I was able to even get that working
>>> in Eclipse. However, it is very basic: no hibernate, no security/
>>> authentication.
>>>
>>> I started following the instructions in the tutorial, which do not work.
>>>
>>> Norman Franke
>>> Answering Service for Directors, Inc.
>>> www.myasd.com
>>>
>>> On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:
>>>>
>>>> did u follow the tapestry quickstart in
>>>> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
>>>> could get easier than this. U can even run it inside eclipse if u have
>>>> the m2 plugin for maven.
>>>>
>>>> i do agree with u that the documentation could be better, however,
>>>> reading your message somebody could believe that starting a new
>>>> tapestry project is extremely difficult and it's totally the contrary.
>>>>
>>>> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com>
>>>>
>>>> wrote:
>>>>>
>>>>> I've been using T4/4.1 for several years and have been quite
>>>>> pleased with
>>>>> it. I've been using it with Hibernate, and while not perfect, it's
>>>>> worked
>>>>> pretty well. We've found it much faster to embed a web browser in
>>>>> our main
>>>>> app and do editing, queries and the like via Tapestry than writing
>>>>> native
>>>>> code.
>>>>>
>>>>> I have a new project to replace our aging billing system. I figured
>>>>> this
>>>>> would be a great way to learn T5. So, I'm migrating me, not an
>>>>> app. :-)
>>>>>
>>>>> I was pondering posting this, but this thread sort of pushed me
>>>>> over the
>>>>> top. Note that I don't disagree with anything Howard said. However,
>>>>> this
>>>>> almost became "Why I almost dumped Tapestry entirely."
>>>>>
>>>>> I'm writing this in order to solicit feedback and maybe help
>>>>> others. I've
>>>>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
>>>>> time time,
>>>>> and I'm very productive developing use them (and T4.1) I think this
>>>>> is a
>>>>> pretty common development environment.
>>>>>
>>>>> To get started in T5 for a fresh new app, my first thought was to
>>>>> follow the
>>>>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>>>>
>>>>> Chapter 2 just plain didn't work for me. I think part of it is due
>>>>> to Maven
>>>>> generally being extremely fragile and working less than half of the
>>>>> time.
>>>>> However, even after working around that, you can't just import the
>>>>> project
>>>>> into Eclipse. At least not under Eclipse 3.4.2.
>>>>>
>>>>> No problem, I thought. Maven is annoying anyway. I'll just create a
>>>>> Dynamic
>>>>> Web project (like I do for T4.1) and download the T5.1 binary
>>>>> distribution.
>>>>> That's even worse. It comes with no README listing dependencies or
>>>>> anything
>>>>> useful, and includes tons of libraries that don't appear to be even
>>>>> needed.
>>>>> Tapestry failed to start up during initialization. Why have a
>>>>> binary distro
>>>>> that doesn't work?
>>>>>
>>>>> Back to Maven. After some googling, I found this article:
>>>>>
>>>>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mave
>>>>> n) Shouldn't
>>>>> this be included in the tutorial? Sadly, the tutorial is extremely
>>>>> basic,
>>>>> but at least it works. (And is the only way I've found to actually
>>>>> create a
>>>>> new project in Eclipse to date.)
>>>>>
>>>>> Next, I tried Tapestry Jumpstart. After hours of configuration and
>>>>> random
>>>>> errors (using Tomcat), it worked. However, it's so fragile and
>>>>> klugy that I
>>>>> just can't see using it in production. I don't care about OpenEJB.
>>>>> I want
>>>>> just plain T5.1 and Hibernate. Plus running in a remote tomcat
>>>>> sessions
>>>>> eliminates many of the developer productivity benefits of T5 in the
>>>>> first
>>>>> place. One thing I liked about T4 was that I could deploy a WAR to
>>>>> a stock
>>>>> Tomcat install, and it would just work. That won't happen with
>>>>> Jumpstart.
>>>>> Plus. it if takes 3 hours to just get a working developer
>>>>> environment, why
>>>>> even bother?
>>>>>
>>>>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
>>>>> Sadly,
>>>>> AppFuse's T4 support is now broken due to a dependancy on tapestry-
>>>>> flash
>>>>> that appears to be missing and following the instructions on the
>>>>> AppFuse
>>>>> Tapestry 5 page doesn't work anymore either, resulting in tons of
>>>>> missing
>>>>> resources.
>>>>>
>>>>> So, since T5 doesn't appear to provide much in the way of
>>>>> authentication /
>>>>> security (a very basic requirement for almost all webapps), I
>>>>> started down
>>>>> the tapestry5-acegi approach. Of course, that doesn't work with
>>>>> T5.1. I
>>>>> managed to get it working and then upgraded to tapestry-spring-
>>>>> security
>>>>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to
>>>>> maven for
>>>>> not updating the packages when I switched to the snapshot, too. I
>>>>> had to
>>>>> delete the "nu" directory in my ~/.m2 directory. One more reason
>>>>> Maven
>>>>> blows. It just doesn't do what you want.)
>>>>>
>>>>> I'd love to see more people use Tapestry, but after attempting a new
>>>>> project, I'd feel embarrassed asking people to give Tapestry a look
>>>>> at this
>>>>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to
>>>>> go, despite
>>>>> all the benefits of T5. But, I really do want to start in on T5
>>>>> since I've
>>>>> loved using T4 for the last few years, and it does seem to be a step
>>>>> forward.
>>>>>
>>>>> I think its common to want to just get something working in order
>>>>> to get a
>>>>> feel for the framework. Doing so in Tapestry, at least for me, has
>>>>> been a
>>>>> waste of two days. I finally, on the third day, I have something that
>>>>> appears to allow the tutorial to work with basic security. I'm not
>>>>> sure if
>>>>> others have similar problems and just gave up without comment,
>>>>> making other
>>>>> frameworks seem more popular?
>>>>>
>>>>> Norman Franke
>>>>> Answering Service for Directors, Inc.
>>>>> www.myasd.com
>>>>>
>>>>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>>>>>
>>>>>> I recently had an e-mail exchange with a Tapestry user; after
>>>>>> congratulating me on creating Tapestry, he went on with the
>>>>>> following
>>>>>> observation on his organization: The company I work at unfortunately
>>>>>> chose JSF for their big app. The reason was that Tapestry was
>>>>>> "brittle"
>>>>>> in the sense that, if one developer breaks something, on a page or a
>>>>>> service, very often the whole site won't come up because the initial
>>>>>> registry startup will fail. Or for example, if page A has a
>>>>>> pagelink to
>>>>>> page B, and page B is broken, then page A won't render. While I
>>>>>> agree
>>>>>> that we shouldn't ship unless the whole app is working, this is a
>>>>>> thousands of pages big app with hundreds of mediocre (as in likely
>>>>>> to
>>>>>> break things) developers. They'd rather have 80% of the thing
>>>>>> working
>>>>>> than nothing at all. I never thought of this for my own projects,
>>>>>> and
>>>>>> haven't had the time to examine the truth of their claims. What's
>>>>>> your
>>>>>> take?
>>>>>> I provided the following response:
>>>>>> Early failures are absolutely, 100%, the only path towards code
>>>>>> quality. You may have heard the phrase "no broken windows" (see "The
>>>>>> Tipping Point" by Malcom Gladwell for more details) but the short
>>>>>> form
>>>>>> is that when errors go uncorrected (whether they are broken
>>>>>> windows in
>>>>>> an abandoned building, or broken code in an application) they tend
>>>>>> to
>>>>>> multiply quite rapidly.
>>>>>> The things that will "break" a link from page A to page B are
>>>>>> substantial problems such as invalid templates, references to
>>>>>> unknown
>>>>>> properties or components, or compile errors in the page B class ...
>>>>>> things that no other developer should ever see when page B's
>>>>>> developer
>>>>>> is working and checking in code. That is, problems that should
>>>>>> never be
>>>>>> checked into trunk, but instead kept in a local workspace or a
>>>>>> private
>>>>>> branch.
>>>>>> An organization that thinks that fail early is a problem is an
>>>>>> organization that isn't prepared to develop a large application in
>>>>>> any
>>>>>> technology. The image I'm getting is one where there is no build
>>>>>> server, no continuous integration, at best CVS for source code
>>>>>> management (or possibly one of those "shared directory"
>>>>>> monstrosities) .... i.e., a chaotic environment where errors are
>>>>>> allowed to be checked in to the trunk and can go unnoticed for some
>>>>>> time.
>>>>>> The solution to coding errors in pages or components is not to wait
>>>>>> until your testers (or end users) find the bugs, but to identify and
>>>>>> fix the bugs early. That's called "engineering discipline" and the
>>>>>> reality is that even self-professed "mediocre" developers can do it.
>>>>>> Tapestry helps because it fails early and has great exception
>>>>>> reporting
>>>>>> to guide you right the problem so that you can fix it.
>>>>>> Another factor here is enforced helplessness. If only Fred
>>>>>> understands
>>>>>> page B and he's out when it's broken, then all development stops
>>>>>> waiting for Fred to get back. I hit this problem myself, years ago
>>>>>> working on a large Struts application (those words give me the
>>>>>> heebie
>>>>>> jeebies now!). We had lots of code, a fragile and slow build
>>>>>> process,
>>>>>> and many little code "fiefdoms". I spent too much wasted time
>>>>>> twiddling
>>>>>> my thumbs.
>>>>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>>>>> normally develops page A) should be free to fix it. Julie will
>>>>>> need to
>>>>>> understand the page B code well enough to fix it, but also you
>>>>>> need an
>>>>>> overall environment with shared source, no repository locks (that
>>>>>> is,
>>>>>> nothing that says "Only Fred can change this file"), and no
>>>>>> management
>>>>>> PHB's getting in the way. Pair programming is the best way for
>>>>>> Fred and
>>>>>> Julie to share knowledge so that they can understand each other's
>>>>>> code.
>>>>>> Even if pairing occurs only part time, it's very effective at
>>>>>> knowledge
>>>>>> transfer as well as ordinary coding.
>>>>>> The idea that "mediocre" developers should use JSF as it is more
>>>>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>>>>> productivity for all developers, by streamlining, simplifying, being
>>>>>> smart and being concise ... not to mention live class reloading and
>>>>>> best-of-breed exception reporting, which makes it fast to identify
>>>>>> and
>>>>>> fix those errors.
>>>>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>>>>> should switch to a diet of fried chicken three meals a day!
>>>>>> Likewise,
>>>>>> if you have concerns with code quality from your developers, you
>>>>>> should
>>>>>> not switch to a less agile, more code-intensive, less supportive
>>>>>> development model and hope to catch all the bugs in QA. Sweeping
>>>>>> problems under the rug is never a winning strategy.
>>>>>> Coming down off my soap box, I should also add that Tapestry 5.1
>>>>>> works
>>>>>> a little bit differently than 5.0 in this respect, so it does (in
>>>>>> fact)
>>>>>> defer more of the page loading and validation until a link is
>>>>>> actually
>>>>>> clicked. This is more for performance reasons than to shield
>>>>>> developers
>>>>>> from application problems. Even in 5.0, the loading and validation
>>>>>> was
>>>>>> the "reach" from page A to pages explicitly referenced (usually via
>>>>>> PageLink during the rendering of page A), so it's a highly unlikely
>>>>>> case that a single error in a 1000 page application will keep the
>>>>>> application from starting up, unless the start page of the
>>>>>> application
>>>>>> links to all 999 other pages.
>>>>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>>>>> quality problems. Quality problems lead to development failures,
>>>>>> schedule slips, missing functionality, low morale and high turnover.
>>>>>> Saying "we don't have time to fix the quality problem first" is to
>>>>>> ignore the the second law of Thermodynamics. You are expecting a
>>>>>> miracle, literally writing it into your project plan.
>>>>>> Formos addresses this issue two ways: First, we use Scrum and
>>>>>> deliver
>>>>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>>>>> constant check on quality (we're providing working code
>>>>>> constantly). We
>>>>>> don't even try to predict what we'll be doing six months or two
>>>>>> years
>>>>>> from now, we just deliver a steady, manageable stream of software.
>>>>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>>>>> anonymous developer's organization rejected it, and for many, many
>>>>>> more
>>>>>> reasons besides.
>>>>>>
>>>>>> --
>>>>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>>
>> --
>> Joel Halbert
>> 020 3051 8637
>> 075 2501 0825
>> joel@su3analytics.com
>> www.su3analytics.com
>> www.storequery.com
>> SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

That's precisely what I was used to. I had to learn much more about  
Maven that I wanted to just get started with a trivial T5 app until I  
found the secret instructions on a blog post from Howard. I haven't  
even tried deploying anything non-trivial yet.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Jun 18, 2009, at 4:37 AM, Joel Halbert wrote:

> I'm still not convinced that using Maven is a good thing.
> It's fine for those people that use it day to day already, but for  
> those
> people who have no need/interest in picking up another framework and  
> who just
> want to get on with using Tapestry its a real bug bear.
>
> I've always just downloaded the binaries for whatever project I'm  
> using and
> dropped them into my project. I very rarely have versioning issues  
> (if every
> at all in fact). I'd go so far as to say that this is preferable -  
> you know
> exactly what code your using, and why, because you've put it there  
> yourself
> rather than having some opaque system under the hood doing it for  
> you. This
> would seem to give you a greater degree of control over whats in your
> environment - important when it comes to deploying.
>
> On Wednesday 17 June 2009 22:15:23 Norman Franke wrote:
>> I did, and that worked using jetty on the command line. Eventually,
>> following the other instructions, I was able to even get that working
>> in Eclipse. However, it is very basic: no hibernate, no security/
>> authentication.
>>
>> I started following the instructions in the tutorial, which do not  
>> work.
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>> On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:
>>> did u follow the tapestry quickstart in
>>> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think  
>>> it
>>> could get easier than this. U can even run it inside eclipse if u  
>>> have
>>> the m2 plugin for maven.
>>>
>>> i do agree with u that the documentation could be better, however,
>>> reading your message somebody could believe that starting a new
>>> tapestry project is extremely difficult and it's totally the  
>>> contrary.
>>>
>>> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com>
>>>
>>> wrote:
>>>> I've been using T4/4.1 for several years and have been quite
>>>> pleased with
>>>> it. I've been using it with Hibernate, and while not perfect, it's
>>>> worked
>>>> pretty well. We've found it much faster to embed a web browser in
>>>> our main
>>>> app and do editing, queries and the like via Tapestry than writing
>>>> native
>>>> code.
>>>>
>>>> I have a new project to replace our aging billing system. I figured
>>>> this
>>>> would be a great way to learn T5. So, I'm migrating me, not an
>>>> app. :-)
>>>>
>>>> I was pondering posting this, but this thread sort of pushed me
>>>> over the
>>>> top. Note that I don't disagree with anything Howard said. However,
>>>> this
>>>> almost became "Why I almost dumped Tapestry entirely."
>>>>
>>>> I'm writing this in order to solicit feedback and maybe help
>>>> others. I've
>>>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
>>>> time time,
>>>> and I'm very productive developing use them (and T4.1) I think this
>>>> is a
>>>> pretty common development environment.
>>>>
>>>> To get started in T5 for a fresh new app, my first thought was to
>>>> follow the
>>>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>>>
>>>> Chapter 2 just plain didn't work for me. I think part of it is due
>>>> to Maven
>>>> generally being extremely fragile and working less than half of the
>>>> time.
>>>> However, even after working around that, you can't just import the
>>>> project
>>>> into Eclipse. At least not under Eclipse 3.4.2.
>>>>
>>>> No problem, I thought. Maven is annoying anyway. I'll just create a
>>>> Dynamic
>>>> Web project (like I do for T4.1) and download the T5.1 binary
>>>> distribution.
>>>> That's even worse. It comes with no README listing dependencies or
>>>> anything
>>>> useful, and includes tons of libraries that don't appear to be even
>>>> needed.
>>>> Tapestry failed to start up during initialization. Why have a
>>>> binary distro
>>>> that doesn't work?
>>>>
>>>> Back to Maven. After some googling, I found this article:
>>>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mave
>>>> n) Shouldn't
>>>> this be included in the tutorial? Sadly, the tutorial is extremely
>>>> basic,
>>>> but at least it works. (And is the only way I've found to actually
>>>> create a
>>>> new project in Eclipse to date.)
>>>>
>>>> Next, I tried Tapestry Jumpstart. After hours of configuration and
>>>> random
>>>> errors (using Tomcat), it worked. However, it's so fragile and
>>>> klugy that I
>>>> just can't see using it in production. I don't care about OpenEJB.
>>>> I want
>>>> just plain T5.1 and Hibernate. Plus running in a remote tomcat
>>>> sessions
>>>> eliminates many of the developer productivity benefits of T5 in the
>>>> first
>>>> place. One thing I liked about T4 was that I could deploy a WAR to
>>>> a stock
>>>> Tomcat install, and it would just work. That won't happen with
>>>> Jumpstart.
>>>> Plus. it if takes 3 hours to just get a working developer
>>>> environment, why
>>>> even bother?
>>>>
>>>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
>>>> Sadly,
>>>> AppFuse's T4 support is now broken due to a dependancy on tapestry-
>>>> flash
>>>> that appears to be missing and following the instructions on the
>>>> AppFuse
>>>> Tapestry 5 page doesn't work anymore either, resulting in tons of
>>>> missing
>>>> resources.
>>>>
>>>> So, since T5 doesn't appear to provide much in the way of
>>>> authentication /
>>>> security (a very basic requirement for almost all webapps), I
>>>> started down
>>>> the tapestry5-acegi approach. Of course, that doesn't work with
>>>> T5.1. I
>>>> managed to get it working and then upgraded to tapestry-spring-
>>>> security
>>>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to
>>>> maven for
>>>> not updating the packages when I switched to the snapshot, too. I
>>>> had to
>>>> delete the "nu" directory in my ~/.m2 directory. One more reason
>>>> Maven
>>>> blows. It just doesn't do what you want.)
>>>>
>>>> I'd love to see more people use Tapestry, but after attempting a  
>>>> new
>>>> project, I'd feel embarrassed asking people to give Tapestry a look
>>>> at this
>>>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to
>>>> go, despite
>>>> all the benefits of T5. But, I really do want to start in on T5
>>>> since I've
>>>> loved using T4 for the last few years, and it does seem to be a  
>>>> step
>>>> forward.
>>>>
>>>> I think its common to want to just get something working in order
>>>> to get a
>>>> feel for the framework. Doing so in Tapestry, at least for me, has
>>>> been a
>>>> waste of two days. I finally, on the third day, I have something  
>>>> that
>>>> appears to allow the tutorial to work with basic security. I'm not
>>>> sure if
>>>> others have similar problems and just gave up without comment,
>>>> making other
>>>> frameworks seem more popular?
>>>>
>>>> Norman Franke
>>>> Answering Service for Directors, Inc.
>>>> www.myasd.com
>>>>
>>>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>>>> I recently had an e-mail exchange with a Tapestry user; after
>>>>> congratulating me on creating Tapestry, he went on with the
>>>>> following
>>>>> observation on his organization: The company I work at  
>>>>> unfortunately
>>>>> chose JSF for their big app. The reason was that Tapestry was
>>>>> "brittle"
>>>>> in the sense that, if one developer breaks something, on a page  
>>>>> or a
>>>>> service, very often the whole site won't come up because the  
>>>>> initial
>>>>> registry startup will fail. Or for example, if page A has a
>>>>> pagelink to
>>>>> page B, and page B is broken, then page A won't render. While I
>>>>> agree
>>>>> that we shouldn't ship unless the whole app is working, this is a
>>>>> thousands of pages big app with hundreds of mediocre (as in likely
>>>>> to
>>>>> break things) developers. They'd rather have 80% of the thing
>>>>> working
>>>>> than nothing at all. I never thought of this for my own projects,
>>>>> and
>>>>> haven't had the time to examine the truth of their claims. What's
>>>>> your
>>>>> take?
>>>>> I provided the following response:
>>>>> Early failures are absolutely, 100%, the only path towards code
>>>>> quality. You may have heard the phrase "no broken windows" (see  
>>>>> "The
>>>>> Tipping Point" by Malcom Gladwell for more details) but the short
>>>>> form
>>>>> is that when errors go uncorrected (whether they are broken
>>>>> windows in
>>>>> an abandoned building, or broken code in an application) they tend
>>>>> to
>>>>> multiply quite rapidly.
>>>>> The things that will "break" a link from page A to page B are
>>>>> substantial problems such as invalid templates, references to
>>>>> unknown
>>>>> properties or components, or compile errors in the page B  
>>>>> class ...
>>>>> things that no other developer should ever see when page B's
>>>>> developer
>>>>> is working and checking in code. That is, problems that should
>>>>> never be
>>>>> checked into trunk, but instead kept in a local workspace or a
>>>>> private
>>>>> branch.
>>>>> An organization that thinks that fail early is a problem is an
>>>>> organization that isn't prepared to develop a large application in
>>>>> any
>>>>> technology. The image I'm getting is one where there is no build
>>>>> server, no continuous integration, at best CVS for source code
>>>>> management (or possibly one of those "shared directory"
>>>>> monstrosities) .... i.e., a chaotic environment where errors are
>>>>> allowed to be checked in to the trunk and can go unnoticed for  
>>>>> some
>>>>> time.
>>>>> The solution to coding errors in pages or components is not to  
>>>>> wait
>>>>> until your testers (or end users) find the bugs, but to identify  
>>>>> and
>>>>> fix the bugs early. That's called "engineering discipline" and the
>>>>> reality is that even self-professed "mediocre" developers can do  
>>>>> it.
>>>>> Tapestry helps because it fails early and has great exception
>>>>> reporting
>>>>> to guide you right the problem so that you can fix it.
>>>>> Another factor here is enforced helplessness. If only Fred
>>>>> understands
>>>>> page B and he's out when it's broken, then all development stops
>>>>> waiting for Fred to get back. I hit this problem myself, years ago
>>>>> working on a large Struts application (those words give me the
>>>>> heebie
>>>>> jeebies now!). We had lots of code, a fragile and slow build
>>>>> process,
>>>>> and many little code "fiefdoms". I spent too much wasted time
>>>>> twiddling
>>>>> my thumbs.
>>>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>>>> normally develops page A) should be free to fix it. Julie will
>>>>> need to
>>>>> understand the page B code well enough to fix it, but also you
>>>>> need an
>>>>> overall environment with shared source, no repository locks (that
>>>>> is,
>>>>> nothing that says "Only Fred can change this file"), and no
>>>>> management
>>>>> PHB's getting in the way. Pair programming is the best way for
>>>>> Fred and
>>>>> Julie to share knowledge so that they can understand each other's
>>>>> code.
>>>>> Even if pairing occurs only part time, it's very effective at
>>>>> knowledge
>>>>> transfer as well as ordinary coding.
>>>>> The idea that "mediocre" developers should use JSF as it is more
>>>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>>>> productivity for all developers, by streamlining, simplifying,  
>>>>> being
>>>>> smart and being concise ... not to mention live class reloading  
>>>>> and
>>>>> best-of-breed exception reporting, which makes it fast to identify
>>>>> and
>>>>> fix those errors.
>>>>> If your doctor tells you to eat less red meat, that doesn't mean  
>>>>> you
>>>>> should switch to a diet of fried chicken three meals a day!
>>>>> Likewise,
>>>>> if you have concerns with code quality from your developers, you
>>>>> should
>>>>> not switch to a less agile, more code-intensive, less supportive
>>>>> development model and hope to catch all the bugs in QA. Sweeping
>>>>> problems under the rug is never a winning strategy.
>>>>> Coming down off my soap box, I should also add that Tapestry 5.1
>>>>> works
>>>>> a little bit differently than 5.0 in this respect, so it does (in
>>>>> fact)
>>>>> defer more of the page loading and validation until a link is
>>>>> actually
>>>>> clicked. This is more for performance reasons than to shield
>>>>> developers
>>>>> from application problems. Even in 5.0, the loading and validation
>>>>> was
>>>>> the "reach" from page A to pages explicitly referenced (usually  
>>>>> via
>>>>> PageLink during the rendering of page A), so it's a highly  
>>>>> unlikely
>>>>> case that a single error in a 1000 page application will keep the
>>>>> application from starting up, unless the start page of the
>>>>> application
>>>>> links to all 999 other pages.
>>>>> Re-reading the above post I can't emphasize enough: you can't  
>>>>> ignore
>>>>> quality problems. Quality problems lead to development failures,
>>>>> schedule slips, missing functionality, low morale and high  
>>>>> turnover.
>>>>> Saying "we don't have time to fix the quality problem first" is to
>>>>> ignore the the second law of Thermodynamics. You are expecting a
>>>>> miracle, literally writing it into your project plan.
>>>>> Formos addresses this issue two ways: First, we use Scrum and
>>>>> deliver
>>>>> on (typically) 4 week cycles. Thus we set real deadlines and  
>>>>> have a
>>>>> constant check on quality (we're providing working code
>>>>> constantly). We
>>>>> don't even try to predict what we'll be doing six months or two
>>>>> years
>>>>> from now, we just deliver a steady, manageable stream of software.
>>>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>>>> anonymous developer's organization rejected it, and for many, many
>>>>> more
>>>>> reasons besides.
>>>>>
>>>>> --
>>>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>
>
>
> -- 
> Joel Halbert
> 020 3051 8637
> 075 2501 0825
> joel@su3analytics.com
> www.su3analytics.com
> www.storequery.com
> SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

Re: [Tapestry Central] Why chose Tapestry?

[Joel Halbert <jo...@su3analytics.com>]

I'm still not convinced that using Maven is a good thing.
It's fine for those people that use it day to day already, but for those 
people who have no need/interest in picking up another framework and who just 
want to get on with using Tapestry its a real bug bear.

I've always just downloaded the binaries for whatever project I'm using and 
dropped them into my project. I very rarely have versioning issues (if every 
at all in fact). I'd go so far as to say that this is preferable - you know 
exactly what code your using, and why, because you've put it there yourself 
rather than having some opaque system under the hood doing it for you. This 
would seem to give you a greater degree of control over whats in your 
environment - important when it comes to deploying.

On Wednesday 17 June 2009 22:15:23 Norman Franke wrote:
> I did, and that worked using jetty on the command line. Eventually,
> following the other instructions, I was able to even get that working
> in Eclipse. However, it is very basic: no hibernate, no security/
> authentication.
>
> I started following the instructions in the tutorial, which do not work.
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
> On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:
> > did u follow the tapestry quickstart in
> > http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> > could get easier than this. U can even run it inside eclipse if u have
> > the m2 plugin for maven.
> >
> > i do agree with u that the documentation could be better, however,
> > reading your message somebody could believe that starting a new
> > tapestry project is extremely difficult and it's totally the contrary.
> >
> > On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com>
> >
> > wrote:
> >> I've been using T4/4.1 for several years and have been quite
> >> pleased with
> >> it. I've been using it with Hibernate, and while not perfect, it's
> >> worked
> >> pretty well. We've found it much faster to embed a web browser in
> >> our main
> >> app and do editing, queries and the like via Tapestry than writing
> >> native
> >> code.
> >>
> >> I have a new project to replace our aging billing system. I figured
> >> this
> >> would be a great way to learn T5. So, I'm migrating me, not an
> >> app. :-)
> >>
> >> I was pondering posting this, but this thread sort of pushed me
> >> over the
> >> top. Note that I don't disagree with anything Howard said. However,
> >> this
> >> almost became "Why I almost dumped Tapestry entirely."
> >>
> >> I'm writing this in order to solicit feedback and maybe help
> >> others. I've
> >> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite
> >> time time,
> >> and I'm very productive developing use them (and T4.1) I think this
> >> is a
> >> pretty common development environment.
> >>
> >> To get started in T5 for a fresh new app, my first thought was to
> >> follow the
> >> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
> >>
> >> Chapter 2 just plain didn't work for me. I think part of it is due
> >> to Maven
> >> generally being extremely fragile and working less than half of the
> >> time.
> >> However, even after working around that, you can't just import the
> >> project
> >> into Eclipse. At least not under Eclipse 3.4.2.
> >>
> >> No problem, I thought. Maven is annoying anyway. I'll just create a
> >> Dynamic
> >> Web project (like I do for T4.1) and download the T5.1 binary
> >> distribution.
> >> That's even worse. It comes with no README listing dependencies or
> >> anything
> >> useful, and includes tons of libraries that don't appear to be even
> >> needed.
> >> Tapestry failed to start up during initialization. Why have a
> >> binary distro
> >> that doesn't work?
> >>
> >> Back to Maven. After some googling, I found this article:
> >> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Mave
> >>n) Shouldn't
> >> this be included in the tutorial? Sadly, the tutorial is extremely
> >> basic,
> >> but at least it works. (And is the only way I've found to actually
> >> create a
> >> new project in Eclipse to date.)
> >>
> >> Next, I tried Tapestry Jumpstart. After hours of configuration and
> >> random
> >> errors (using Tomcat), it worked. However, it's so fragile and
> >> klugy that I
> >> just can't see using it in production. I don't care about OpenEJB.
> >> I want
> >> just plain T5.1 and Hibernate. Plus running in a remote tomcat
> >> sessions
> >> eliminates many of the developer productivity benefits of T5 in the
> >> first
> >> place. One thing I liked about T4 was that I could deploy a WAR to
> >> a stock
> >> Tomcat install, and it would just work. That won't happen with
> >> Jumpstart.
> >> Plus. it if takes 3 hours to just get a working developer
> >> environment, why
> >> even bother?
> >>
> >> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.
> >> Sadly,
> >> AppFuse's T4 support is now broken due to a dependancy on tapestry-
> >> flash
> >> that appears to be missing and following the instructions on the
> >> AppFuse
> >> Tapestry 5 page doesn't work anymore either, resulting in tons of
> >> missing
> >> resources.
> >>
> >> So, since T5 doesn't appear to provide much in the way of
> >> authentication /
> >> security (a very basic requirement for almost all webapps), I
> >> started down
> >> the tapestry5-acegi approach. Of course, that doesn't work with
> >> T5.1. I
> >> managed to get it working and then upgraded to tapestry-spring-
> >> security
> >> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to
> >> maven for
> >> not updating the packages when I switched to the snapshot, too. I
> >> had to
> >> delete the "nu" directory in my ~/.m2 directory. One more reason
> >> Maven
> >> blows. It just doesn't do what you want.)
> >>
> >> I'd love to see more people use Tapestry, but after attempting a new
> >> project, I'd feel embarrassed asking people to give Tapestry a look
> >> at this
> >> point. Heck, I'm thinking maybe sticking with T4.1 is the way to
> >> go, despite
> >> all the benefits of T5. But, I really do want to start in on T5
> >> since I've
> >> loved using T4 for the last few years, and it does seem to be a step
> >> forward.
> >>
> >> I think its common to want to just get something working in order
> >> to get a
> >> feel for the framework. Doing so in Tapestry, at least for me, has
> >> been a
> >> waste of two days. I finally, on the third day, I have something that
> >> appears to allow the tutorial to work with basic security. I'm not
> >> sure if
> >> others have similar problems and just gave up without comment,
> >> making other
> >> frameworks seem more popular?
> >>
> >> Norman Franke
> >> Answering Service for Directors, Inc.
> >> www.myasd.com
> >>
> >> On Jun 16, 2009, at 7:20 PM, Howard wrote:
> >>> I recently had an e-mail exchange with a Tapestry user; after
> >>> congratulating me on creating Tapestry, he went on with the
> >>> following
> >>> observation on his organization: The company I work at unfortunately
> >>> chose JSF for their big app. The reason was that Tapestry was
> >>> "brittle"
> >>> in the sense that, if one developer breaks something, on a page or a
> >>> service, very often the whole site won't come up because the initial
> >>> registry startup will fail. Or for example, if page A has a
> >>> pagelink to
> >>> page B, and page B is broken, then page A won't render. While I
> >>> agree
> >>> that we shouldn't ship unless the whole app is working, this is a
> >>> thousands of pages big app with hundreds of mediocre (as in likely
> >>> to
> >>> break things) developers. They'd rather have 80% of the thing
> >>> working
> >>> than nothing at all. I never thought of this for my own projects,
> >>> and
> >>> haven't had the time to examine the truth of their claims. What's
> >>> your
> >>> take?
> >>> I provided the following response:
> >>> Early failures are absolutely, 100%, the only path towards code
> >>> quality. You may have heard the phrase "no broken windows" (see "The
> >>> Tipping Point" by Malcom Gladwell for more details) but the short
> >>> form
> >>> is that when errors go uncorrected (whether they are broken
> >>> windows in
> >>> an abandoned building, or broken code in an application) they tend
> >>> to
> >>> multiply quite rapidly.
> >>> The things that will "break" a link from page A to page B are
> >>> substantial problems such as invalid templates, references to
> >>> unknown
> >>> properties or components, or compile errors in the page B class ...
> >>> things that no other developer should ever see when page B's
> >>> developer
> >>> is working and checking in code. That is, problems that should
> >>> never be
> >>> checked into trunk, but instead kept in a local workspace or a
> >>> private
> >>> branch.
> >>> An organization that thinks that fail early is a problem is an
> >>> organization that isn't prepared to develop a large application in
> >>> any
> >>> technology. The image I'm getting is one where there is no build
> >>> server, no continuous integration, at best CVS for source code
> >>> management (or possibly one of those "shared directory"
> >>> monstrosities) .... i.e., a chaotic environment where errors are
> >>> allowed to be checked in to the trunk and can go unnoticed for some
> >>> time.
> >>> The solution to coding errors in pages or components is not to wait
> >>> until your testers (or end users) find the bugs, but to identify and
> >>> fix the bugs early. That's called "engineering discipline" and the
> >>> reality is that even self-professed "mediocre" developers can do it.
> >>> Tapestry helps because it fails early and has great exception
> >>> reporting
> >>> to guide you right the problem so that you can fix it.
> >>> Another factor here is enforced helplessness. If only Fred
> >>> understands
> >>> page B and he's out when it's broken, then all development stops
> >>> waiting for Fred to get back. I hit this problem myself, years ago
> >>> working on a large Struts application (those words give me the
> >>> heebie
> >>> jeebies now!). We had lots of code, a fragile and slow build
> >>> process,
> >>> and many little code "fiefdoms". I spent too much wasted time
> >>> twiddling
> >>> my thumbs.
> >>> Nobody should "own the code"; if page B is is broken, Julie (who
> >>> normally develops page A) should be free to fix it. Julie will
> >>> need to
> >>> understand the page B code well enough to fix it, but also you
> >>> need an
> >>> overall environment with shared source, no repository locks (that
> >>> is,
> >>> nothing that says "Only Fred can change this file"), and no
> >>> management
> >>> PHB's getting in the way. Pair programming is the best way for
> >>> Fred and
> >>> Julie to share knowledge so that they can understand each other's
> >>> code.
> >>> Even if pairing occurs only part time, it's very effective at
> >>> knowledge
> >>> transfer as well as ordinary coding.
> >>> The idea that "mediocre" developers should use JSF as it is more
> >>> tolerant of errors is absurd! Tapestry 5 is designed to improve
> >>> productivity for all developers, by streamlining, simplifying, being
> >>> smart and being concise ... not to mention live class reloading and
> >>> best-of-breed exception reporting, which makes it fast to identify
> >>> and
> >>> fix those errors.
> >>> If your doctor tells you to eat less red meat, that doesn't mean you
> >>> should switch to a diet of fried chicken three meals a day!
> >>> Likewise,
> >>> if you have concerns with code quality from your developers, you
> >>> should
> >>> not switch to a less agile, more code-intensive, less supportive
> >>> development model and hope to catch all the bugs in QA. Sweeping
> >>> problems under the rug is never a winning strategy.
> >>> Coming down off my soap box, I should also add that Tapestry 5.1
> >>> works
> >>> a little bit differently than 5.0 in this respect, so it does (in
> >>> fact)
> >>> defer more of the page loading and validation until a link is
> >>> actually
> >>> clicked. This is more for performance reasons than to shield
> >>> developers
> >>> from application problems. Even in 5.0, the loading and validation
> >>> was
> >>> the "reach" from page A to pages explicitly referenced (usually via
> >>> PageLink during the rendering of page A), so it's a highly unlikely
> >>> case that a single error in a 1000 page application will keep the
> >>> application from starting up, unless the start page of the
> >>> application
> >>> links to all 999 other pages.
> >>> Re-reading the above post I can't emphasize enough: you can't ignore
> >>> quality problems. Quality problems lead to development failures,
> >>> schedule slips, missing functionality, low morale and high turnover.
> >>> Saying "we don't have time to fix the quality problem first" is to
> >>> ignore the the second law of Thermodynamics. You are expecting a
> >>> miracle, literally writing it into your project plan.
> >>> Formos addresses this issue two ways: First, we use Scrum and
> >>> deliver
> >>> on (typically) 4 week cycles. Thus we set real deadlines and have a
> >>> constant check on quality (we're providing working code
> >>> constantly). We
> >>> don't even try to predict what we'll be doing six months or two
> >>> years
> >>> from now, we just deliver a steady, manageable stream of software.
> >>> Secondly, Formos uses Tapestry because of all the reasons that the
> >>> anonymous developer's organization rejected it, and for many, many
> >>> more
> >>> reasons besides.
> >>>
> >>> --
> >>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> > For additional commands, e-mail: users-help@tapestry.apache.org



-- 
Joel Halbert
020 3051 8637
075 2501 0825
joel@su3analytics.com
www.su3analytics.com
www.storequery.com
SU3 Analytics Ltd, The Print House, 18 Ashwin St, London E8 3DL.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Olle Hallin <ol...@gmail.com>]

The text in http://tapestry.apache.org/tapestry5.1/quickstart/ is ambiguous.

In one place it says *-DarchetypeCatalog=
http://tapestry.formos.com/maven-repository*, but inside the
example box there's *-DarchetypeCatalog=
http://tapestry.formos.com/maven-snapshot-repository* which does not work.

*Unfortunately, many users see only the latter url!*

Olle

2009/6/17 Norman Franke <no...@myasd.com>

> I did, and that worked using jetty on the command line. Eventually,
> following the other instructions, I was able to even get that working in
> Eclipse. However, it is very basic: no hibernate, no
> security/authentication.
>
> I started following the instructions in the tutorial, which do not work.
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:
>
>  did u follow the tapestry quickstart in
>> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
>> could get easier than this. U can even run it inside eclipse if u have
>> the m2 plugin for maven.
>>
>> i do agree with u that the documentation could be better, however,
>> reading your message somebody could believe that starting a new
>> tapestry project is extremely difficult and it's totally the contrary.
>>
>> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com> wrote:
>>
>>> I've been using T4/4.1 for several years and have been quite pleased with
>>> it. I've been using it with Hibernate, and while not perfect, it's worked
>>> pretty well. We've found it much faster to embed a web browser in our
>>> main
>>> app and do editing, queries and the like via Tapestry than writing native
>>> code.
>>>
>>> I have a new project to replace our aging billing system. I figured this
>>> would be a great way to learn T5. So, I'm migrating me, not an app. :-)
>>>
>>> I was pondering posting this, but this thread sort of pushed me over the
>>> top. Note that I don't disagree with anything Howard said. However, this
>>> almost became "Why I almost dumped Tapestry entirely."
>>>
>>> I'm writing this in order to solicit feedback and maybe help others. I've
>>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time
>>> time,
>>> and I'm very productive developing use them (and T4.1) I think this is a
>>> pretty common development environment.
>>>
>>> To get started in T5 for a fresh new app, my first thought was to follow
>>> the
>>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>>
>>> Chapter 2 just plain didn't work for me. I think part of it is due to
>>> Maven
>>> generally being extremely fragile and working less than half of the time.
>>> However, even after working around that, you can't just import the
>>> project
>>> into Eclipse. At least not under Eclipse 3.4.2.
>>>
>>> No problem, I thought. Maven is annoying anyway. I'll just create a
>>> Dynamic
>>> Web project (like I do for T4.1) and download the T5.1 binary
>>> distribution.
>>> That's even worse. It comes with no README listing dependencies or
>>> anything
>>> useful, and includes tons of libraries that don't appear to be even
>>> needed.
>>> Tapestry failed to start up during initialization. Why have a binary
>>> distro
>>> that doesn't work?
>>>
>>> Back to Maven. After some googling, I found this article:
>>>
>>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven)<http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+%28including+Maven%29>
>>>  Shouldn't
>>> this be included in the tutorial? Sadly, the tutorial is extremely basic,
>>> but at least it works. (And is the only way I've found to actually create
>>> a
>>> new project in Eclipse to date.)
>>>
>>> Next, I tried Tapestry Jumpstart. After hours of configuration and random
>>> errors (using Tomcat), it worked. However, it's so fragile and klugy that
>>> I
>>> just can't see using it in production. I don't care about OpenEJB. I want
>>> just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions
>>> eliminates many of the developer productivity benefits of T5 in the first
>>> place. One thing I liked about T4 was that I could deploy a WAR to a
>>> stock
>>> Tomcat install, and it would just work. That won't happen with Jumpstart.
>>> Plus. it if takes 3 hours to just get a working developer environment,
>>> why
>>> even bother?
>>>
>>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly,
>>> AppFuse's T4 support is now broken due to a dependancy on tapestry-flash
>>> that appears to be missing and following the instructions on the AppFuse
>>> Tapestry 5 page doesn't work anymore either, resulting in tons of missing
>>> resources.
>>>
>>> So, since T5 doesn't appear to provide much in the way of authentication
>>> /
>>> security (a very basic requirement for almost all webapps), I started
>>> down
>>> the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I
>>> managed to get it working and then upgraded to tapestry-spring-security
>>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven
>>> for
>>> not updating the packages when I switched to the snapshot, too. I had to
>>> delete the "nu" directory in my ~/.m2 directory. One more reason Maven
>>> blows. It just doesn't do what you want.)
>>>
>>> I'd love to see more people use Tapestry, but after attempting a new
>>> project, I'd feel embarrassed asking people to give Tapestry a look at
>>> this
>>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to go,
>>> despite
>>> all the benefits of T5. But, I really do want to start in on T5 since
>>> I've
>>> loved using T4 for the last few years, and it does seem to be a step
>>> forward.
>>>
>>> I think its common to want to just get something working in order to get
>>> a
>>> feel for the framework. Doing so in Tapestry, at least for me, has been a
>>> waste of two days. I finally, on the third day, I have something that
>>> appears to allow the tutorial to work with basic security. I'm not sure
>>> if
>>> others have similar problems and just gave up without comment, making
>>> other
>>> frameworks seem more popular?
>>>
>>> Norman Franke
>>> Answering Service for Directors, Inc.
>>> www.myasd.com
>>>
>>>
>>>
>>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>>
>>>  I recently had an e-mail exchange with a Tapestry user; after
>>>> congratulating me on creating Tapestry, he went on with the following
>>>> observation on his organization: The company I work at unfortunately
>>>> chose JSF for their big app. The reason was that Tapestry was "brittle"
>>>> in the sense that, if one developer breaks something, on a page or a
>>>> service, very often the whole site won't come up because the initial
>>>> registry startup will fail. Or for example, if page A has a pagelink to
>>>> page B, and page B is broken, then page A won't render. While I agree
>>>> that we shouldn't ship unless the whole app is working, this is a
>>>> thousands of pages big app with hundreds of mediocre (as in likely to
>>>> break things) developers. They'd rather have 80% of the thing working
>>>> than nothing at all. I never thought of this for my own projects, and
>>>> haven't had the time to examine the truth of their claims. What's your
>>>> take?
>>>> I provided the following response:
>>>> Early failures are absolutely, 100%, the only path towards code
>>>> quality. You may have heard the phrase "no broken windows" (see "The
>>>> Tipping Point" by Malcom Gladwell for more details) but the short form
>>>> is that when errors go uncorrected (whether they are broken windows in
>>>> an abandoned building, or broken code in an application) they tend to
>>>> multiply quite rapidly.
>>>> The things that will "break" a link from page A to page B are
>>>> substantial problems such as invalid templates, references to unknown
>>>> properties or components, or compile errors in the page B class ...
>>>> things that no other developer should ever see when page B's developer
>>>> is working and checking in code. That is, problems that should never be
>>>> checked into trunk, but instead kept in a local workspace or a private
>>>> branch.
>>>> An organization that thinks that fail early is a problem is an
>>>> organization that isn't prepared to develop a large application in any
>>>> technology. The image I'm getting is one where there is no build
>>>> server, no continuous integration, at best CVS for source code
>>>> management (or possibly one of those "shared directory"
>>>> monstrosities) .... i.e., a chaotic environment where errors are
>>>> allowed to be checked in to the trunk and can go unnoticed for some
>>>> time.
>>>> The solution to coding errors in pages or components is not to wait
>>>> until your testers (or end users) find the bugs, but to identify and
>>>> fix the bugs early. That's called "engineering discipline" and the
>>>> reality is that even self-professed "mediocre" developers can do it.
>>>> Tapestry helps because it fails early and has great exception reporting
>>>> to guide you right the problem so that you can fix it.
>>>> Another factor here is enforced helplessness. If only Fred understands
>>>> page B and he's out when it's broken, then all development stops
>>>> waiting for Fred to get back. I hit this problem myself, years ago
>>>> working on a large Struts application (those words give me the heebie
>>>> jeebies now!). We had lots of code, a fragile and slow build process,
>>>> and many little code "fiefdoms". I spent too much wasted time twiddling
>>>> my thumbs.
>>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>>> normally develops page A) should be free to fix it. Julie will need to
>>>> understand the page B code well enough to fix it, but also you need an
>>>> overall environment with shared source, no repository locks (that is,
>>>> nothing that says "Only Fred can change this file"), and no management
>>>> PHB's getting in the way. Pair programming is the best way for Fred and
>>>> Julie to share knowledge so that they can understand each other's code.
>>>> Even if pairing occurs only part time, it's very effective at knowledge
>>>> transfer as well as ordinary coding.
>>>> The idea that "mediocre" developers should use JSF as it is more
>>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>>> productivity for all developers, by streamlining, simplifying, being
>>>> smart and being concise ... not to mention live class reloading and
>>>> best-of-breed exception reporting, which makes it fast to identify and
>>>> fix those errors.
>>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>>> should switch to a diet of fried chicken three meals a day! Likewise,
>>>> if you have concerns with code quality from your developers, you should
>>>> not switch to a less agile, more code-intensive, less supportive
>>>> development model and hope to catch all the bugs in QA. Sweeping
>>>> problems under the rug is never a winning strategy.
>>>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>>>> a little bit differently than 5.0 in this respect, so it does (in fact)
>>>> defer more of the page loading and validation until a link is actually
>>>> clicked. This is more for performance reasons than to shield developers
>>>> from application problems. Even in 5.0, the loading and validation was
>>>> the "reach" from page A to pages explicitly referenced (usually via
>>>> PageLink during the rendering of page A), so it's a highly unlikely
>>>> case that a single error in a 1000 page application will keep the
>>>> application from starting up, unless the start page of the application
>>>> links to all 999 other pages.
>>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>>> quality problems. Quality problems lead to development failures,
>>>> schedule slips, missing functionality, low morale and high turnover.
>>>> Saying "we don't have time to fix the quality problem first" is to
>>>> ignore the the second law of Thermodynamics. You are expecting a
>>>> miracle, literally writing it into your project plan.
>>>> Formos addresses this issue two ways: First, we use Scrum and deliver
>>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>>> constant check on quality (we're providing working code constantly). We
>>>> don't even try to predict what we'll be doing six months or two years
>>>> from now, we just deliver a steady, manageable stream of software.
>>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>>> anonymous developer's organization rejected it, and for many, many more
>>>> reasons besides.
>>>>
>>>> --
>>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>>>
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>>
>


-- 
Olle Hallin
Senior Java Developer and Architect
olle.hallin@crisp.se
www.crisp.se

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

I did, and that worked using jetty on the command line. Eventually,  
following the other instructions, I was able to even get that working  
in Eclipse. However, it is very basic: no hibernate, no security/ 
authentication.

I started following the instructions in the tutorial, which do not work.

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Jun 17, 2009, at 2:21 PM, Juan E. Maya wrote:

> did u follow the tapestry quickstart in
> http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
> could get easier than this. U can even run it inside eclipse if u have
> the m2 plugin for maven.
>
> i do agree with u that the documentation could be better, however,
> reading your message somebody could believe that starting a new
> tapestry project is extremely difficult and it's totally the contrary.
>
> On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com>  
> wrote:
>> I've been using T4/4.1 for several years and have been quite  
>> pleased with
>> it. I've been using it with Hibernate, and while not perfect, it's  
>> worked
>> pretty well. We've found it much faster to embed a web browser in  
>> our main
>> app and do editing, queries and the like via Tapestry than writing  
>> native
>> code.
>>
>> I have a new project to replace our aging billing system. I figured  
>> this
>> would be a great way to learn T5. So, I'm migrating me, not an  
>> app. :-)
>>
>> I was pondering posting this, but this thread sort of pushed me  
>> over the
>> top. Note that I don't disagree with anything Howard said. However,  
>> this
>> almost became "Why I almost dumped Tapestry entirely."
>>
>> I'm writing this in order to solicit feedback and maybe help  
>> others. I've
>> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite  
>> time time,
>> and I'm very productive developing use them (and T4.1) I think this  
>> is a
>> pretty common development environment.
>>
>> To get started in T5 for a fresh new app, my first thought was to  
>> follow the
>> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>>
>> Chapter 2 just plain didn't work for me. I think part of it is due  
>> to Maven
>> generally being extremely fragile and working less than half of the  
>> time.
>> However, even after working around that, you can't just import the  
>> project
>> into Eclipse. At least not under Eclipse 3.4.2.
>>
>> No problem, I thought. Maven is annoying anyway. I'll just create a  
>> Dynamic
>> Web project (like I do for T4.1) and download the T5.1 binary  
>> distribution.
>> That's even worse. It comes with no README listing dependencies or  
>> anything
>> useful, and includes tons of libraries that don't appear to be even  
>> needed.
>> Tapestry failed to start up during initialization. Why have a  
>> binary distro
>> that doesn't work?
>>
>> Back to Maven. After some googling, I found this article:
>> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) 
>>  Shouldn't
>> this be included in the tutorial? Sadly, the tutorial is extremely  
>> basic,
>> but at least it works. (And is the only way I've found to actually  
>> create a
>> new project in Eclipse to date.)
>>
>> Next, I tried Tapestry Jumpstart. After hours of configuration and  
>> random
>> errors (using Tomcat), it worked. However, it's so fragile and  
>> klugy that I
>> just can't see using it in production. I don't care about OpenEJB.  
>> I want
>> just plain T5.1 and Hibernate. Plus running in a remote tomcat  
>> sessions
>> eliminates many of the developer productivity benefits of T5 in the  
>> first
>> place. One thing I liked about T4 was that I could deploy a WAR to  
>> a stock
>> Tomcat install, and it would just work. That won't happen with  
>> Jumpstart.
>> Plus. it if takes 3 hours to just get a working developer  
>> environment, why
>> even bother?
>>
>> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.  
>> Sadly,
>> AppFuse's T4 support is now broken due to a dependancy on tapestry- 
>> flash
>> that appears to be missing and following the instructions on the  
>> AppFuse
>> Tapestry 5 page doesn't work anymore either, resulting in tons of  
>> missing
>> resources.
>>
>> So, since T5 doesn't appear to provide much in the way of  
>> authentication /
>> security (a very basic requirement for almost all webapps), I  
>> started down
>> the tapestry5-acegi approach. Of course, that doesn't work with  
>> T5.1. I
>> managed to get it working and then upgraded to tapestry-spring- 
>> security
>> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to  
>> maven for
>> not updating the packages when I switched to the snapshot, too. I  
>> had to
>> delete the "nu" directory in my ~/.m2 directory. One more reason  
>> Maven
>> blows. It just doesn't do what you want.)
>>
>> I'd love to see more people use Tapestry, but after attempting a new
>> project, I'd feel embarrassed asking people to give Tapestry a look  
>> at this
>> point. Heck, I'm thinking maybe sticking with T4.1 is the way to  
>> go, despite
>> all the benefits of T5. But, I really do want to start in on T5  
>> since I've
>> loved using T4 for the last few years, and it does seem to be a step
>> forward.
>>
>> I think its common to want to just get something working in order  
>> to get a
>> feel for the framework. Doing so in Tapestry, at least for me, has  
>> been a
>> waste of two days. I finally, on the third day, I have something that
>> appears to allow the tutorial to work with basic security. I'm not  
>> sure if
>> others have similar problems and just gave up without comment,  
>> making other
>> frameworks seem more popular?
>>
>> Norman Franke
>> Answering Service for Directors, Inc.
>> www.myasd.com
>>
>>
>>
>> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>>
>>> I recently had an e-mail exchange with a Tapestry user; after
>>> congratulating me on creating Tapestry, he went on with the  
>>> following
>>> observation on his organization: The company I work at unfortunately
>>> chose JSF for their big app. The reason was that Tapestry was  
>>> "brittle"
>>> in the sense that, if one developer breaks something, on a page or a
>>> service, very often the whole site won't come up because the initial
>>> registry startup will fail. Or for example, if page A has a  
>>> pagelink to
>>> page B, and page B is broken, then page A won't render. While I  
>>> agree
>>> that we shouldn't ship unless the whole app is working, this is a
>>> thousands of pages big app with hundreds of mediocre (as in likely  
>>> to
>>> break things) developers. They'd rather have 80% of the thing  
>>> working
>>> than nothing at all. I never thought of this for my own projects,  
>>> and
>>> haven't had the time to examine the truth of their claims. What's  
>>> your
>>> take?
>>> I provided the following response:
>>> Early failures are absolutely, 100%, the only path towards code
>>> quality. You may have heard the phrase "no broken windows" (see "The
>>> Tipping Point" by Malcom Gladwell for more details) but the short  
>>> form
>>> is that when errors go uncorrected (whether they are broken  
>>> windows in
>>> an abandoned building, or broken code in an application) they tend  
>>> to
>>> multiply quite rapidly.
>>> The things that will "break" a link from page A to page B are
>>> substantial problems such as invalid templates, references to  
>>> unknown
>>> properties or components, or compile errors in the page B class ...
>>> things that no other developer should ever see when page B's  
>>> developer
>>> is working and checking in code. That is, problems that should  
>>> never be
>>> checked into trunk, but instead kept in a local workspace or a  
>>> private
>>> branch.
>>> An organization that thinks that fail early is a problem is an
>>> organization that isn't prepared to develop a large application in  
>>> any
>>> technology. The image I'm getting is one where there is no build
>>> server, no continuous integration, at best CVS for source code
>>> management (or possibly one of those "shared directory"
>>> monstrosities) .... i.e., a chaotic environment where errors are
>>> allowed to be checked in to the trunk and can go unnoticed for some
>>> time.
>>> The solution to coding errors in pages or components is not to wait
>>> until your testers (or end users) find the bugs, but to identify and
>>> fix the bugs early. That's called "engineering discipline" and the
>>> reality is that even self-professed "mediocre" developers can do it.
>>> Tapestry helps because it fails early and has great exception  
>>> reporting
>>> to guide you right the problem so that you can fix it.
>>> Another factor here is enforced helplessness. If only Fred  
>>> understands
>>> page B and he's out when it's broken, then all development stops
>>> waiting for Fred to get back. I hit this problem myself, years ago
>>> working on a large Struts application (those words give me the  
>>> heebie
>>> jeebies now!). We had lots of code, a fragile and slow build  
>>> process,
>>> and many little code "fiefdoms". I spent too much wasted time  
>>> twiddling
>>> my thumbs.
>>> Nobody should "own the code"; if page B is is broken, Julie (who
>>> normally develops page A) should be free to fix it. Julie will  
>>> need to
>>> understand the page B code well enough to fix it, but also you  
>>> need an
>>> overall environment with shared source, no repository locks (that  
>>> is,
>>> nothing that says "Only Fred can change this file"), and no  
>>> management
>>> PHB's getting in the way. Pair programming is the best way for  
>>> Fred and
>>> Julie to share knowledge so that they can understand each other's  
>>> code.
>>> Even if pairing occurs only part time, it's very effective at  
>>> knowledge
>>> transfer as well as ordinary coding.
>>> The idea that "mediocre" developers should use JSF as it is more
>>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>>> productivity for all developers, by streamlining, simplifying, being
>>> smart and being concise ... not to mention live class reloading and
>>> best-of-breed exception reporting, which makes it fast to identify  
>>> and
>>> fix those errors.
>>> If your doctor tells you to eat less red meat, that doesn't mean you
>>> should switch to a diet of fried chicken three meals a day!  
>>> Likewise,
>>> if you have concerns with code quality from your developers, you  
>>> should
>>> not switch to a less agile, more code-intensive, less supportive
>>> development model and hope to catch all the bugs in QA. Sweeping
>>> problems under the rug is never a winning strategy.
>>> Coming down off my soap box, I should also add that Tapestry 5.1  
>>> works
>>> a little bit differently than 5.0 in this respect, so it does (in  
>>> fact)
>>> defer more of the page loading and validation until a link is  
>>> actually
>>> clicked. This is more for performance reasons than to shield  
>>> developers
>>> from application problems. Even in 5.0, the loading and validation  
>>> was
>>> the "reach" from page A to pages explicitly referenced (usually via
>>> PageLink during the rendering of page A), so it's a highly unlikely
>>> case that a single error in a 1000 page application will keep the
>>> application from starting up, unless the start page of the  
>>> application
>>> links to all 999 other pages.
>>> Re-reading the above post I can't emphasize enough: you can't ignore
>>> quality problems. Quality problems lead to development failures,
>>> schedule slips, missing functionality, low morale and high turnover.
>>> Saying "we don't have time to fix the quality problem first" is to
>>> ignore the the second law of Thermodynamics. You are expecting a
>>> miracle, literally writing it into your project plan.
>>> Formos addresses this issue two ways: First, we use Scrum and  
>>> deliver
>>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>>> constant check on quality (we're providing working code  
>>> constantly). We
>>> don't even try to predict what we'll be doing six months or two  
>>> years
>>> from now, we just deliver a steady, manageable stream of software.
>>> Secondly, Formos uses Tapestry because of all the reasons that the
>>> anonymous developer's organization rejected it, and for many, many  
>>> more
>>> reasons besides.
>>>
>>> --
>>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

Re: [Tapestry Central] Why chose Tapestry?

["Juan E. Maya" <ma...@gmail.com>]

did u follow the tapestry quickstart in
http://tapestry.apache.org/tapestry5.1/quickstart/ ? I don't think it
could get easier than this. U can even run it inside eclipse if u have
the m2 plugin for maven.

i do agree with u that the documentation could be better, however,
reading your message somebody could believe that starting a new
tapestry project is extremely difficult and it's totally the contrary.

On Wed, Jun 17, 2009 at 7:21 PM, Norman Franke<no...@myasd.com> wrote:
> I've been using T4/4.1 for several years and have been quite pleased with
> it. I've been using it with Hibernate, and while not perfect, it's worked
> pretty well. We've found it much faster to embed a web browser in our main
> app and do editing, queries and the like via Tapestry than writing native
> code.
>
> I have a new project to replace our aging billing system. I figured this
> would be a great way to learn T5. So, I'm migrating me, not an app. :-)
>
> I was pondering posting this, but this thread sort of pushed me over the
> top. Note that I don't disagree with anything Howard said. However, this
> almost became "Why I almost dumped Tapestry entirely."
>
> I'm writing this in order to solicit feedback and maybe help others. I've
> been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite time time,
> and I'm very productive developing use them (and T4.1) I think this is a
> pretty common development environment.
>
> To get started in T5 for a fresh new app, my first thought was to follow the
> tutorial at http://tapestry.apache.org/tapestry5.1/tutorial1/.
>
> Chapter 2 just plain didn't work for me. I think part of it is due to Maven
> generally being extremely fragile and working less than half of the time.
> However, even after working around that, you can't just import the project
> into Eclipse. At least not under Eclipse 3.4.2.
>
> No problem, I thought. Maven is annoying anyway. I'll just create a Dynamic
> Web project (like I do for T4.1) and download the T5.1 binary distribution.
> That's even worse. It comes with no README listing dependencies or anything
> useful, and includes tons of libraries that don't appear to be even needed.
> Tapestry failed to start up during initialization. Why have a binary distro
> that doesn't work?
>
> Back to Maven. After some googling, I found this article:
> http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) Shouldn't
> this be included in the tutorial? Sadly, the tutorial is extremely basic,
> but at least it works. (And is the only way I've found to actually create a
> new project in Eclipse to date.)
>
> Next, I tried Tapestry Jumpstart. After hours of configuration and random
> errors (using Tomcat), it worked. However, it's so fragile and klugy that I
> just can't see using it in production. I don't care about OpenEJB. I want
> just plain T5.1 and Hibernate. Plus running in a remote tomcat sessions
> eliminates many of the developer productivity benefits of T5 in the first
> place. One thing I liked about T4 was that I could deploy a WAR to a stock
> Tomcat install, and it would just work. That won't happen with Jumpstart.
> Plus. it if takes 3 hours to just get a working developer environment, why
> even bother?
>
> Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on. Sadly,
> AppFuse's T4 support is now broken due to a dependancy on tapestry-flash
> that appears to be missing and following the instructions on the AppFuse
> Tapestry 5 page doesn't work anymore either, resulting in tons of missing
> resources.
>
> So, since T5 doesn't appear to provide much in the way of authentication /
> security (a very basic requirement for almost all webapps), I started down
> the tapestry5-acegi approach. Of course, that doesn't work with T5.1. I
> managed to get it working and then upgraded to tapestry-spring-security
> 2.1.0-SNAPSHOT. Still didn't work without augmentation. (Thanks to maven for
> not updating the packages when I switched to the snapshot, too. I had to
> delete the "nu" directory in my ~/.m2 directory. One more reason Maven
> blows. It just doesn't do what you want.)
>
> I'd love to see more people use Tapestry, but after attempting a new
> project, I'd feel embarrassed asking people to give Tapestry a look at this
> point. Heck, I'm thinking maybe sticking with T4.1 is the way to go, despite
> all the benefits of T5. But, I really do want to start in on T5 since I've
> loved using T4 for the last few years, and it does seem to be a step
> forward.
>
> I think its common to want to just get something working in order to get a
> feel for the framework. Doing so in Tapestry, at least for me, has been a
> waste of two days. I finally, on the third day, I have something that
> appears to allow the tutorial to work with basic security. I'm not sure if
> others have similar problems and just gave up without comment, making other
> frameworks seem more popular?
>
> Norman Franke
> Answering Service for Directors, Inc.
> www.myasd.com
>
>
>
> On Jun 16, 2009, at 7:20 PM, Howard wrote:
>
>> I recently had an e-mail exchange with a Tapestry user; after
>> congratulating me on creating Tapestry, he went on with the following
>> observation on his organization: The company I work at unfortunately
>> chose JSF for their big app. The reason was that Tapestry was "brittle"
>> in the sense that, if one developer breaks something, on a page or a
>> service, very often the whole site won't come up because the initial
>> registry startup will fail. Or for example, if page A has a pagelink to
>> page B, and page B is broken, then page A won't render. While I agree
>> that we shouldn't ship unless the whole app is working, this is a
>> thousands of pages big app with hundreds of mediocre (as in likely to
>> break things) developers. They'd rather have 80% of the thing working
>> than nothing at all. I never thought of this for my own projects, and
>> haven't had the time to examine the truth of their claims. What's your
>> take?
>> I provided the following response:
>> Early failures are absolutely, 100%, the only path towards code
>> quality. You may have heard the phrase "no broken windows" (see "The
>> Tipping Point" by Malcom Gladwell for more details) but the short form
>> is that when errors go uncorrected (whether they are broken windows in
>> an abandoned building, or broken code in an application) they tend to
>> multiply quite rapidly.
>> The things that will "break" a link from page A to page B are
>> substantial problems such as invalid templates, references to unknown
>> properties or components, or compile errors in the page B class ...
>> things that no other developer should ever see when page B's developer
>> is working and checking in code. That is, problems that should never be
>> checked into trunk, but instead kept in a local workspace or a private
>> branch.
>> An organization that thinks that fail early is a problem is an
>> organization that isn't prepared to develop a large application in any
>> technology. The image I'm getting is one where there is no build
>> server, no continuous integration, at best CVS for source code
>> management (or possibly one of those "shared directory"
>> monstrosities) .... i.e., a chaotic environment where errors are
>> allowed to be checked in to the trunk and can go unnoticed for some
>> time.
>> The solution to coding errors in pages or components is not to wait
>> until your testers (or end users) find the bugs, but to identify and
>> fix the bugs early. That's called "engineering discipline" and the
>> reality is that even self-professed "mediocre" developers can do it.
>> Tapestry helps because it fails early and has great exception reporting
>> to guide you right the problem so that you can fix it.
>> Another factor here is enforced helplessness. If only Fred understands
>> page B and he's out when it's broken, then all development stops
>> waiting for Fred to get back. I hit this problem myself, years ago
>> working on a large Struts application (those words give me the heebie
>> jeebies now!). We had lots of code, a fragile and slow build process,
>> and many little code "fiefdoms". I spent too much wasted time twiddling
>> my thumbs.
>> Nobody should "own the code"; if page B is is broken, Julie (who
>> normally develops page A) should be free to fix it. Julie will need to
>> understand the page B code well enough to fix it, but also you need an
>> overall environment with shared source, no repository locks (that is,
>> nothing that says "Only Fred can change this file"), and no management
>> PHB's getting in the way. Pair programming is the best way for Fred and
>> Julie to share knowledge so that they can understand each other's code.
>> Even if pairing occurs only part time, it's very effective at knowledge
>> transfer as well as ordinary coding.
>> The idea that "mediocre" developers should use JSF as it is more
>> tolerant of errors is absurd! Tapestry 5 is designed to improve
>> productivity for all developers, by streamlining, simplifying, being
>> smart and being concise ... not to mention live class reloading and
>> best-of-breed exception reporting, which makes it fast to identify and
>> fix those errors.
>> If your doctor tells you to eat less red meat, that doesn't mean you
>> should switch to a diet of fried chicken three meals a day! Likewise,
>> if you have concerns with code quality from your developers, you should
>> not switch to a less agile, more code-intensive, less supportive
>> development model and hope to catch all the bugs in QA. Sweeping
>> problems under the rug is never a winning strategy.
>> Coming down off my soap box, I should also add that Tapestry 5.1 works
>> a little bit differently than 5.0 in this respect, so it does (in fact)
>> defer more of the page loading and validation until a link is actually
>> clicked. This is more for performance reasons than to shield developers
>> from application problems. Even in 5.0, the loading and validation was
>> the "reach" from page A to pages explicitly referenced (usually via
>> PageLink during the rendering of page A), so it's a highly unlikely
>> case that a single error in a 1000 page application will keep the
>> application from starting up, unless the start page of the application
>> links to all 999 other pages.
>> Re-reading the above post I can't emphasize enough: you can't ignore
>> quality problems. Quality problems lead to development failures,
>> schedule slips, missing functionality, low morale and high turnover.
>> Saying "we don't have time to fix the quality problem first" is to
>> ignore the the second law of Thermodynamics. You are expecting a
>> miracle, literally writing it into your project plan.
>> Formos addresses this issue two ways: First, we use Scrum and deliver
>> on (typically) 4 week cycles. Thus we set real deadlines and have a
>> constant check on quality (we're providing working code constantly). We
>> don't even try to predict what we'll be doing six months or two years
>> from now, we just deliver a steady, manageable stream of software.
>> Secondly, Formos uses Tapestry because of all the reasons that the
>> anonymous developer's organization rejected it, and for many, many more
>> reasons besides.
>>
>> --
>> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org

Re: [Tapestry Central] Why chose Tapestry?

[Norman Franke <no...@myasd.com>]

I've been using T4/4.1 for several years and have been quite pleased  
with it. I've been using it with Hibernate, and while not perfect,  
it's worked pretty well. We've found it much faster to embed a web  
browser in our main app and do editing, queries and the like via  
Tapestry than writing native code.

I have a new project to replace our aging billing system. I figured  
this would be a great way to learn T5. So, I'm migrating me, not an  
app. :-)

I was pondering posting this, but this thread sort of pushed me over  
the top. Note that I don't disagree with anything Howard said.  
However, this almost became "Why I almost dumped Tapestry entirely."

I'm writing this in order to solicit feedback and maybe help others.  
I've been using Tomcat (now 6.0.20) and Eclipse (now 3.4.2) for quite  
time time, and I'm very productive developing use them (and T4.1) I  
think this is a pretty common development environment.

To get started in T5 for a fresh new app, my first thought was to  
follow the tutorial at http://tapestry.apache.org/tapestry5.1/ 
tutorial1/.

Chapter 2 just plain didn't work for me. I think part of it is due to  
Maven generally being extremely fragile and working less than half of  
the time. However, even after working around that, you can't just  
import the project into Eclipse. At least not under Eclipse 3.4.2.

No problem, I thought. Maven is annoying anyway. I'll just create a  
Dynamic Web project (like I do for T4.1) and download the T5.1 binary  
distribution. That's even worse. It comes with no README listing  
dependencies or anything useful, and includes tons of libraries that  
don't appear to be even needed. Tapestry failed to start up during  
initialization. Why have a binary distro that doesn't work?

Back to Maven. After some googling, I found this article: http://tapestry.formos.com/wiki/display/T5IDEINT/Eclipse+(including+Maven) 
  Shouldn't this be included in the tutorial? Sadly, the tutorial is  
extremely basic, but at least it works. (And is the only way I've  
found to actually create a new project in Eclipse to date.)

Next, I tried Tapestry Jumpstart. After hours of configuration and  
random errors (using Tomcat), it worked. However, it's so fragile and  
klugy that I just can't see using it in production. I don't care about  
OpenEJB. I want just plain T5.1 and Hibernate. Plus running in a  
remote tomcat sessions eliminates many of the developer productivity  
benefits of T5 in the first place. One thing I liked about T4 was that  
I could deploy a WAR to a stock Tomcat install, and it would just  
work. That won't happen with Jumpstart. Plus. it if takes 3 hours to  
just get a working developer environment, why even bother?

Next up, AppFuse. It's only T4, but there is a Tapestry 5 add-on.  
Sadly, AppFuse's T4 support is now broken due to a dependancy on  
tapestry-flash that appears to be missing and following the  
instructions on the AppFuse Tapestry 5 page doesn't work anymore  
either, resulting in tons of missing resources.

So, since T5 doesn't appear to provide much in the way of  
authentication / security (a very basic requirement for almost all  
webapps), I started down the tapestry5-acegi approach. Of course, that  
doesn't work with T5.1. I managed to get it working and then upgraded  
to tapestry-spring-security 2.1.0-SNAPSHOT. Still didn't work without  
augmentation. (Thanks to maven for not updating the packages when I  
switched to the snapshot, too. I had to delete the "nu" directory in  
my ~/.m2 directory. One more reason Maven blows. It just doesn't do  
what you want.)

I'd love to see more people use Tapestry, but after attempting a new  
project, I'd feel embarrassed asking people to give Tapestry a look at  
this point. Heck, I'm thinking maybe sticking with T4.1 is the way to  
go, despite all the benefits of T5. But, I really do want to start in  
on T5 since I've loved using T4 for the last few years, and it does  
seem to be a step forward.

I think its common to want to just get something working in order to  
get a feel for the framework. Doing so in Tapestry, at least for me,  
has been a waste of two days. I finally, on the third day, I have  
something that appears to allow the tutorial to work with basic  
security. I'm not sure if others have similar problems and just gave  
up without comment, making other frameworks seem more popular?

Norman Franke
Answering Service for Directors, Inc.
www.myasd.com



On Jun 16, 2009, at 7:20 PM, Howard wrote:

> I recently had an e-mail exchange with a Tapestry user; after
> congratulating me on creating Tapestry, he went on with the following
> observation on his organization: The company I work at unfortunately
> chose JSF for their big app. The reason was that Tapestry was  
> "brittle"
> in the sense that, if one developer breaks something, on a page or a
> service, very often the whole site won't come up because the initial
> registry startup will fail. Or for example, if page A has a pagelink  
> to
> page B, and page B is broken, then page A won't render. While I agree
> that we shouldn't ship unless the whole app is working, this is a
> thousands of pages big app with hundreds of mediocre (as in likely to
> break things) developers. They'd rather have 80% of the thing working
> than nothing at all. I never thought of this for my own projects, and
> haven't had the time to examine the truth of their claims. What's your
> take?
> I provided the following response:
> Early failures are absolutely, 100%, the only path towards code
> quality. You may have heard the phrase "no broken windows" (see "The
> Tipping Point" by Malcom Gladwell for more details) but the short form
> is that when errors go uncorrected (whether they are broken windows in
> an abandoned building, or broken code in an application) they tend to
> multiply quite rapidly.
> The things that will "break" a link from page A to page B are
> substantial problems such as invalid templates, references to unknown
> properties or components, or compile errors in the page B class ...
> things that no other developer should ever see when page B's developer
> is working and checking in code. That is, problems that should never  
> be
> checked into trunk, but instead kept in a local workspace or a private
> branch.
> An organization that thinks that fail early is a problem is an
> organization that isn't prepared to develop a large application in any
> technology. The image I'm getting is one where there is no build
> server, no continuous integration, at best CVS for source code
> management (or possibly one of those "shared directory"
> monstrosities) .... i.e., a chaotic environment where errors are
> allowed to be checked in to the trunk and can go unnoticed for some
> time.
> The solution to coding errors in pages or components is not to wait
> until your testers (or end users) find the bugs, but to identify and
> fix the bugs early. That's called "engineering discipline" and the
> reality is that even self-professed "mediocre" developers can do it.
> Tapestry helps because it fails early and has great exception  
> reporting
> to guide you right the problem so that you can fix it.
> Another factor here is enforced helplessness. If only Fred understands
> page B and he's out when it's broken, then all development stops
> waiting for Fred to get back. I hit this problem myself, years ago
> working on a large Struts application (those words give me the heebie
> jeebies now!). We had lots of code, a fragile and slow build process,
> and many little code "fiefdoms". I spent too much wasted time  
> twiddling
> my thumbs.
> Nobody should "own the code"; if page B is is broken, Julie (who
> normally develops page A) should be free to fix it. Julie will need to
> understand the page B code well enough to fix it, but also you need an
> overall environment with shared source, no repository locks (that is,
> nothing that says "Only Fred can change this file"), and no management
> PHB's getting in the way. Pair programming is the best way for Fred  
> and
> Julie to share knowledge so that they can understand each other's  
> code.
> Even if pairing occurs only part time, it's very effective at  
> knowledge
> transfer as well as ordinary coding.
> The idea that "mediocre" developers should use JSF as it is more
> tolerant of errors is absurd! Tapestry 5 is designed to improve
> productivity for all developers, by streamlining, simplifying, being
> smart and being concise ... not to mention live class reloading and
> best-of-breed exception reporting, which makes it fast to identify and
> fix those errors.
> If your doctor tells you to eat less red meat, that doesn't mean you
> should switch to a diet of fried chicken three meals a day! Likewise,
> if you have concerns with code quality from your developers, you  
> should
> not switch to a less agile, more code-intensive, less supportive
> development model and hope to catch all the bugs in QA. Sweeping
> problems under the rug is never a winning strategy.
> Coming down off my soap box, I should also add that Tapestry 5.1 works
> a little bit differently than 5.0 in this respect, so it does (in  
> fact)
> defer more of the page loading and validation until a link is actually
> clicked. This is more for performance reasons than to shield  
> developers
> from application problems. Even in 5.0, the loading and validation was
> the "reach" from page A to pages explicitly referenced (usually via
> PageLink during the rendering of page A), so it's a highly unlikely
> case that a single error in a 1000 page application will keep the
> application from starting up, unless the start page of the application
> links to all 999 other pages.
> Re-reading the above post I can't emphasize enough: you can't ignore
> quality problems. Quality problems lead to development failures,
> schedule slips, missing functionality, low morale and high turnover.
> Saying "we don't have time to fix the quality problem first" is to
> ignore the the second law of Thermodynamics. You are expecting a
> miracle, literally writing it into your project plan.
> Formos addresses this issue two ways: First, we use Scrum and deliver
> on (typically) 4 week cycles. Thus we set real deadlines and have a
> constant check on quality (we're providing working code constantly).  
> We
> don't even try to predict what we'll be doing six months or two years
> from now, we just deliver a steady, manageable stream of software.
> Secondly, Formos uses Tapestry because of all the reasons that the
> anonymous developer's organization rejected it, and for many, many  
> more
> reasons besides.
>
> --
> Posted By Howard to Tapestry Central at 6/16/2009 03:45:00 PM