Re: Components to fry JSF and all other frameworks

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Michael Musson
Personally I am excited about the prospects of HiveMind and Tapestry
together. I am relatively new to Tapestry but I work on large systems.
Tapestry in its current version is a nice web GUI. However, Tapestry +
HiveMind starts to look like a powerful application framework for
building big complicated systems.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Components to fry JSF and all other frameworks

Patrick Casey

        For me I'm not interested in a soup to nuts framework. If I was, I'd
be running on .net, Websphere, or JBoss. For me at least, I'd rather
tapestry were a *smoking good* web gui framework, than a "quite good" full
featured framework. In other words I'd like it to be narrowly focused but
really, really good at what it does instead of trying to do everything and
inevitably not doing it as well.

        Of course I'm not a tapestry dev; I'm a user, so what I *want* to
happen may not match what the community as a whole wants to happen.
Likewise, the devs are the only vote that really counts :).

        --- Pat

-----Original Message-----
From: Michael Musson [mailto:[hidden email]]
Sent: Thursday, May 05, 2005 10:13 PM
To: Tapestry users
Subject: Re: Components to fry JSF and all other frameworks

Personally I am excited about the prospects of HiveMind and Tapestry
together. I am relatively new to Tapestry but I work on large systems.
Tapestry in its current version is a nice web GUI. However, Tapestry +
HiveMind starts to look like a powerful application framework for
building big complicated systems.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]




---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Brian K. Wallace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While I understand the sentiment you present below, I must disagree.
You, as a user, *should* have the loudest vote. Not that all of every
user's wants and desires will ever be filled, but the users are the
community. If you want something, speak up. If you get a lot of other
users saying it's a bad idea - well, whether it is or not it probably
won't get voted to the top of the heap of changes. Still doesn't mean it
can't end up in the codebase, just means you'd probably have to be the
one to step outside the 'user' role and implement it. In emphasizing
'should' above I acknowledge that there is usually a guiding direction
(usually being more often than not in an ideal world) that may either
eliminate or modify the needs or wants presented in a current version.
However I do not believe that the Tapestry community is just the core
that brought it into Apache and under Jakarta. There is still a sense of
directing everything toward Howard for 'approval', but I see this as
more of a case of him providing an overall direction and no real
objections presented to that direction. In the early days I did not
quite feel that (it was Howard's baby and he knew it better than
anyone), but as the community has grown and more people are utilizing
*JIRA* (note: Jira is not just for bugs) and taking Tapestry outside the
box in which it had previously been implemented it appears as though
more and more the users are powering the development. If not powering,
at least empowering. (please disregard any words that appear marketing
in nature ;-))

All that said, yes - the committers do have the only votes that _really_
count - as in "binding". However, I have yet to see a -1 from anyone
participating in a vote - binding or not - be ignored. You want the
kitchen sink before you'll change your -1? Alright - you'd probably be
vetoed. But the key to this, and any other project, is the path forward.
And all the committers, while having their own views (which may or may
not match anyone else's - not even Howard's), have shown their
willingness to discuss changes.

As to the Hivemind dependency being an 'added' layer - if you look at
the core of what Tapestry requires, both pre and post Hivemind change,
you'll see that there are no truly new requirements of users. You can
still do what you've been doing and achieve the same results.
Refactoring the code to separate more of what Hivemind does best into
the Hivemind codebase and pointing Tapestry to use it doesn't add a
whole lot more to what Tapestry requires and does add a whole lot more
to what Tapestry can provide. If I write no log statements, I still
depend on logging. If I use no Hivemind integration in Tapestry, I still
depend on it. Same concept. If it makes it so developers (not speaking
of commiters here) can more easily create the cool components - I'm all
for it. And if it makes it easier for developers (speaking Tapestry
developers here) to stay flexible in the future direction of Tapestry -
I'm all for that as well.

My .02


Patrick Casey wrote:
| Of course I'm not a tapestry dev; I'm a user, so what I *want* to
| happen may not match what the community as a whole wants to happen.
| Likewise, the devs are the only vote that really counts :).
|
| --- Pat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCexYSaCoPKRow/gARAjKQAKChIC9rOTZ1APmhpBg1rdGC/FCMxwCgri9z
4PToslltH7nku5yMm7rek4k=
=0Hbg
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Moving .properties files

Kuon
Hello,

In my application, I moved the HTML template to

/templates/

instead of
/WEB-INF/

I added

   <context-asset name="$template"  path="/templates/Home/Home.html"/>

for example to the Home page (I created subfolder with page name for
localization purposes).

My .page are in /WEB-INF/pages

everything work well and I'm happy.

But for some pages, I want to add a .properties file for message
localization purposes (like text email, logFile comments...)

It work well if I put the .properties next to the .page, but I want to
put the .properties next to the .html.

Like

/templates/Home/Home.html
Home_en.html
Home_jp.html
Home.properties
Home_en.properties
Home_jp.properties

and so one.

Any idea?

Regards

Kuon

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: Components to fry JSF and all other frameworks

Karthik Abram
In reply to this post by Brian K. Wallace

I've not seen one blog/article/email that convinces me HiveMind provides any
capabilities to the component writer. I believe there are changes being made
to simplify writing components a bit, but still, they don't require
HiveMind. HiveMind will also hamper the adoption of Tapestry to some extent.
Corporations now have to accept another OSS into their support structure. If
a HiveMind like framework is required, then why no Spring which is clearly
more popular?

I agree with Patrick - there are lots of features (e.g. rewind cycle) that
can be worked on. The documentation - which is outdated (including the book)
can be brought up-to-speed. The famed Tapestry learning curve can be
addressed with good examples ...

In the end, OSS is also a player in the free market. I think it is telling
that Tapestry is technically a better framework, but has so small a
marketshare. Not the first time I've seen this.

-----Original Message-----
From: Brian K. Wallace [mailto:[hidden email]]
Sent: Friday, May 06, 2005 3:01 AM
To: Tapestry users
Subject: Re: Components to fry JSF and all other frameworks


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

While I understand the sentiment you present below, I must disagree.
You, as a user, *should* have the loudest vote. Not that all of every
user's wants and desires will ever be filled, but the users are the
community. If you want something, speak up. If you get a lot of other
users saying it's a bad idea - well, whether it is or not it probably
won't get voted to the top of the heap of changes. Still doesn't mean it
can't end up in the codebase, just means you'd probably have to be the
one to step outside the 'user' role and implement it. In emphasizing
'should' above I acknowledge that there is usually a guiding direction
(usually being more often than not in an ideal world) that may either
eliminate or modify the needs or wants presented in a current version.
However I do not believe that the Tapestry community is just the core
that brought it into Apache and under Jakarta. There is still a sense of
directing everything toward Howard for 'approval', but I see this as
more of a case of him providing an overall direction and no real
objections presented to that direction. In the early days I did not
quite feel that (it was Howard's baby and he knew it better than
anyone), but as the community has grown and more people are utilizing
*JIRA* (note: Jira is not just for bugs) and taking Tapestry outside the
box in which it had previously been implemented it appears as though
more and more the users are powering the development. If not powering,
at least empowering. (please disregard any words that appear marketing
in nature ;-))

All that said, yes - the committers do have the only votes that _really_
count - as in "binding". However, I have yet to see a -1 from anyone
participating in a vote - binding or not - be ignored. You want the
kitchen sink before you'll change your -1? Alright - you'd probably be
vetoed. But the key to this, and any other project, is the path forward.
And all the committers, while having their own views (which may or may
not match anyone else's - not even Howard's), have shown their
willingness to discuss changes.

As to the Hivemind dependency being an 'added' layer - if you look at
the core of what Tapestry requires, both pre and post Hivemind change,
you'll see that there are no truly new requirements of users. You can
still do what you've been doing and achieve the same results.
Refactoring the code to separate more of what Hivemind does best into
the Hivemind codebase and pointing Tapestry to use it doesn't add a
whole lot more to what Tapestry requires and does add a whole lot more
to what Tapestry can provide. If I write no log statements, I still
depend on logging. If I use no Hivemind integration in Tapestry, I still
depend on it. Same concept. If it makes it so developers (not speaking
of commiters here) can more easily create the cool components - I'm all
for it. And if it makes it easier for developers (speaking Tapestry
developers here) to stay flexible in the future direction of Tapestry -
I'm all for that as well.

My .02


Patrick Casey wrote:
| Of course I'm not a tapestry dev; I'm a user, so what I *want* to
| happen may not match what the community as a whole wants to happen.
| Likewise, the devs are the only vote that really counts :).
|
| --- Pat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCexYSaCoPKRow/gARAjKQAKChIC9rOTZ1APmhpBg1rdGC/FCMxwCgri9z
4PToslltH7nku5yMm7rek4k=
=0Hbg
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Gregg D Bolinger
I'll add my 2 cents here.  A lot of good points either way you look at
it in this thread.

I'd argue that what draws people to ASP.NET is not the components.  It
is the speed in which you can click out a web application in VS.NET.
[sidetrack] I hear a lot of people rant and rave about VB.NET because
of how fast you can build GUI's.  Well, it's not VB the language that
makes that possible.  It's VS.NET. [/sidetrack].

So I think the component argument should be aimed at JSF, Wicket, etc
because in all honestly I don't believe Tapestry is competing against
.NET.

I personally like Tapestry.  And I am all for change as long as it is
for the better.  Don't take one step foward and 2 steps back just to
make the framework *cooler*.

My biggest complaint about Tapestry 4.0, or whatever it will be
called, is that it is integrated with HiveMind.  These are 2 different
project solving 2 different problems.  I don't think an IoC container
should be in the same distribution as a Web App Framework.  With that
being said, I don't know how Howard is planning on using them
together.  I haven't had a chance to look at any of the new Tapestry
stuff yet.

I am hoping that IoC still remains a developers option when using
Tapestry.  How hard will it be to use Spring instead of HiveMind if I
want?  Is that even possible?

BTW - I've taken a look at Wicket and while it does look like a
Tapestry clone, it is coming along quite nicely.  If I am forced to
use HiveMind with the new Tapestry, I'll use Wicket. :)

Gregg Bolinger



On 5/6/05, Karthik Abram <[hidden email]> wrote:

>
> I've not seen one blog/article/email that convinces me HiveMind provides any
> capabilities to the component writer. I believe there are changes being made
> to simplify writing components a bit, but still, they don't require
> HiveMind. HiveMind will also hamper the adoption of Tapestry to some extent.
> Corporations now have to accept another OSS into their support structure. If
> a HiveMind like framework is required, then why no Spring which is clearly
> more popular?
>
> I agree with Patrick - there are lots of features (e.g. rewind cycle) that
> can be worked on. The documentation - which is outdated (including the book)
> can be brought up-to-speed. The famed Tapestry learning curve can be
> addressed with good examples ...
>
> In the end, OSS is also a player in the free market. I think it is telling
> that Tapestry is technically a better framework, but has so small a
> marketshare. Not the first time I've seen this.
>
> -----Original Message-----
> From: Brian K. Wallace [mailto:[hidden email]]
> Sent: Friday, May 06, 2005 3:01 AM
> To: Tapestry users
> Subject: Re: Components to fry JSF and all other frameworks
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> While I understand the sentiment you present below, I must disagree.
> You, as a user, *should* have the loudest vote. Not that all of every
> user's wants and desires will ever be filled, but the users are the
> community. If you want something, speak up. If you get a lot of other
> users saying it's a bad idea - well, whether it is or not it probably
> won't get voted to the top of the heap of changes. Still doesn't mean it
> can't end up in the codebase, just means you'd probably have to be the
> one to step outside the 'user' role and implement it. In emphasizing
> 'should' above I acknowledge that there is usually a guiding direction
> (usually being more often than not in an ideal world) that may either
> eliminate or modify the needs or wants presented in a current version.
> However I do not believe that the Tapestry community is just the core
> that brought it into Apache and under Jakarta. There is still a sense of
> directing everything toward Howard for 'approval', but I see this as
> more of a case of him providing an overall direction and no real
> objections presented to that direction. In the early days I did not
> quite feel that (it was Howard's baby and he knew it better than
> anyone), but as the community has grown and more people are utilizing
> *JIRA* (note: Jira is not just for bugs) and taking Tapestry outside the
> box in which it had previously been implemented it appears as though
> more and more the users are powering the development. If not powering,
> at least empowering. (please disregard any words that appear marketing
> in nature ;-))
>
> All that said, yes - the committers do have the only votes that _really_
> count - as in "binding". However, I have yet to see a -1 from anyone
> participating in a vote - binding or not - be ignored. You want the
> kitchen sink before you'll change your -1? Alright - you'd probably be
> vetoed. But the key to this, and any other project, is the path forward.
> And all the committers, while having their own views (which may or may
> not match anyone else's - not even Howard's), have shown their
> willingness to discuss changes.
>
> As to the Hivemind dependency being an 'added' layer - if you look at
> the core of what Tapestry requires, both pre and post Hivemind change,
> you'll see that there are no truly new requirements of users. You can
> still do what you've been doing and achieve the same results.
> Refactoring the code to separate more of what Hivemind does best into
> the Hivemind codebase and pointing Tapestry to use it doesn't add a
> whole lot more to what Tapestry requires and does add a whole lot more
> to what Tapestry can provide. If I write no log statements, I still
> depend on logging. If I use no Hivemind integration in Tapestry, I still
> depend on it. Same concept. If it makes it so developers (not speaking
> of commiters here) can more easily create the cool components - I'm all
> for it. And if it makes it easier for developers (speaking Tapestry
> developers here) to stay flexible in the future direction of Tapestry -
> I'm all for that as well.
>
> My .02
>
> Patrick Casey wrote:
> |       Of course I'm not a tapestry dev; I'm a user, so what I *want* to
> | happen may not match what the community as a whole wants to happen.
> | Likewise, the devs are the only vote that really counts :).
> |
> |       --- Pat
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.5 (MingW32)
>
> iD8DBQFCexYSaCoPKRow/gARAjKQAKChIC9rOTZ1APmhpBg1rdGC/FCMxwCgri9z
> 4PToslltH7nku5yMm7rek4k=
> =0Hbg
> -----END PGP SIGNATURE-----
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Howard Lewis Ship
Nobody is forced to use HiveMind. It's there. Tapestry uses it to coordinate
the many moving parts of its infrastructure. It's convienient for
applications, or they can use whatever they want. The new, higher level of
expressiveness has allowed Tapestry to move forward in deep and subtle ways.
It's allowed me to get code tested that wasn't testable in the past. Spring
does not have the level of expressiveness needed by Tapestry.

I don't understand why people will subscribe to an IoC container for thier
applications (which are often relatively trivial) and not for an underlying
framework, especially one with the internal complexity and extensibility of
Tapestry. 3.0, lacking an IoC container, was largely tapped out in terms of
extending it, and fixing the issues many people really struggle with
(parameter direction and so forth).

My Mantra is "Less Is More". I want less code, less XML, less HTML. 4.0 is
headed in the right direction by that measure. Simplcitiy, Consistency,
Efficiency, Feedback. 4.0 is an improvement on 3.0 in terms of all four
principles. Refactoring around HiveMind is largely the reason.

If you want whizz bang components right now, go write some. Tapestry has had
the necessary support, server-side and client-side, including dynamic
JavaScript, for quite some time now (2 - 3 years). There are limits to what
can be packaged with Tapestry proper, due to licensing, so I think the
really interesting (Ajax) components are always going to be a seperate
project.

The "take my ball and go home" argument doesn't carry much weight either.
I'd really prefer to see some encouragment here. I've invested years of my
life, and the equivalent of $200,000+ in lost wages, into Tapestry. When I
see messages that accuse me of some kind of intellectual self-indulgence, it
can be pretty de-motivating.



On 5/6/05, Gregg D Bolinger <[hidden email]> wrote:
> I'll add my 2 cents here. A lot of good points either way you look at
> it in this thread.
>
> I'd argue that what draws people to ASP.NET <http://ASP.NET> is not the
components. It
> is the speed in which you can click out a web application in VS.NET<http://VS.NET>
.

> [sidetrack] I hear a lot of people rant and rave about VB.NET<http://VB.NET>because
> of how fast you can build GUI's. Well, it's not VB the language that
> makes that possible. It's VS.NET <http://VS.NET>. [/sidetrack].
>
> So I think the component argument should be aimed at JSF, Wicket, etc
> because in all honestly I don't believe Tapestry is competing against
> .NET.
>
> I personally like Tapestry. And I am all for change as long as it is
> for the better. Don't take one step foward and 2 steps back just to
> make the framework *cooler*.
>
> My biggest complaint about Tapestry 4.0, or whatever it will be
> called, is that it is integrated with HiveMind. These are 2 different
> project solving 2 different problems. I don't think an IoC container
> should be in the same distribution as a Web App Framework. With that
> being said, I don't know how Howard is planning on using them
> together. I haven't had a chance to look at any of the new Tapestry
> stuff yet.
>
> I am hoping that IoC still remains a developers option when using
> Tapestry. How hard will it be to use Spring instead of HiveMind if I
> want? Is that even possible?
>
> BTW - I've taken a look at Wicket and while it does look like a
> Tapestry clone, it is coming along quite nicely. If I am forced to
> use HiveMind with the new Tapestry, I'll use Wicket. :)
>
> Gregg Bolinger
>
>
> On 5/6/05, Karthik Abram <[hidden email]> wrote:
> >
> > I've not seen one blog/article/email that convinces me HiveMind provides
any
> > capabilities to the component writer. I believe there are changes being
made
> > to simplify writing components a bit, but still, they don't require
> > HiveMind. HiveMind will also hamper the adoption of Tapestry to some
extent.
> > Corporations now have to accept another OSS into their support
structure. If
> > a HiveMind like framework is required, then why no Spring which is
clearly
> > more popular?
> >
> > I agree with Patrick - there are lots of features (e.g. rewind cycle)
that
> > can be worked on. The documentation - which is outdated (including the
book)
> > can be brought up-to-speed. The famed Tapestry learning curve can be
> > addressed with good examples ...
> >
> > In the end, OSS is also a player in the free market. I think it is
telling

> > that Tapestry is technically a better framework, but has so small a
> > marketshare. Not the first time I've seen this.
> >
> > -----Original Message-----
> > From: Brian K. Wallace [mailto:[hidden email]]
> > Sent: Friday, May 06, 2005 3:01 AM
> > To: Tapestry users
> > Subject: Re: Components to fry JSF and all other frameworks
> >
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > While I understand the sentiment you present below, I must disagree.
> > You, as a user, *should* have the loudest vote. Not that all of every
> > user's wants and desires will ever be filled, but the users are the
> > community. If you want something, speak up. If you get a lot of other
> > users saying it's a bad idea - well, whether it is or not it probably
> > won't get voted to the top of the heap of changes. Still doesn't mean it
> > can't end up in the codebase, just means you'd probably have to be the
> > one to step outside the 'user' role and implement it. In emphasizing
> > 'should' above I acknowledge that there is usually a guiding direction
> > (usually being more often than not in an ideal world) that may either
> > eliminate or modify the needs or wants presented in a current version.
> > However I do not believe that the Tapestry community is just the core
> > that brought it into Apache and under Jakarta. There is still a sense of
> > directing everything toward Howard for 'approval', but I see this as
> > more of a case of him providing an overall direction and no real
> > objections presented to that direction. In the early days I did not
> > quite feel that (it was Howard's baby and he knew it better than
> > anyone), but as the community has grown and more people are utilizing
> > *JIRA* (note: Jira is not just for bugs) and taking Tapestry outside the
> > box in which it had previously been implemented it appears as though
> > more and more the users are powering the development. If not powering,
> > at least empowering. (please disregard any words that appear marketing
> > in nature ;-))
> >
> > All that said, yes - the committers do have the only votes that _really_
> > count - as in "binding". However, I have yet to see a -1 from anyone
> > participating in a vote - binding or not - be ignored. You want the
> > kitchen sink before you'll change your -1? Alright - you'd probably be
> > vetoed. But the key to this, and any other project, is the path forward.
> > And all the committers, while having their own views (which may or may
> > not match anyone else's - not even Howard's), have shown their
> > willingness to discuss changes.
> >
> > As to the Hivemind dependency being an 'added' layer - if you look at
> > the core of what Tapestry requires, both pre and post Hivemind change,
> > you'll see that there are no truly new requirements of users. You can
> > still do what you've been doing and achieve the same results.
> > Refactoring the code to separate more of what Hivemind does best into
> > the Hivemind codebase and pointing Tapestry to use it doesn't add a
> > whole lot more to what Tapestry requires and does add a whole lot more
> > to what Tapestry can provide. If I write no log statements, I still
> > depend on logging. If I use no Hivemind integration in Tapestry, I still
> > depend on it. Same concept. If it makes it so developers (not speaking
> > of commiters here) can more easily create the cool components - I'm all
> > for it. And if it makes it easier for developers (speaking Tapestry
> > developers here) to stay flexible in the future direction of Tapestry -
> > I'm all for that as well.
> >
> > My .02
> >
> > Patrick Casey wrote:
> > | Of course I'm not a tapestry dev; I'm a user, so what I *want* to
> > | happen may not match what the community as a whole wants to happen.
> > | Likewise, the devs are the only vote that really counts :).
> > |
> > | --- Pat
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.2.5 (MingW32)
> >
> > iD8DBQFCexYSaCoPKRow/gARAjKQAKChIC9rOTZ1APmhpBg1rdGC/FCMxwCgri9z
> > 4PToslltH7nku5yMm7rek4k=
> > =0Hbg
> > -----END PGP SIGNATURE-----
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind

Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
Reply | Threaded
Open this post in threaded view
|

RE: Components to fry JSF and all other frameworks

Patrick Casey

<snip>

I don't understand why people will subscribe to an IoC container for thier
applications (which are often relatively trivial) and not for an underlying
framework, especially one with the internal complexity and extensibility of
Tapestry. 3.0, lacking an IoC container, was largely tapped out in terms of
extending it, and fixing the issues many people really struggle with
(parameter direction and so forth).

*** PMC for me at least it comes down to scope. A full on web application
framework like JBOSS or WebSphere is such a monstrous learning cliff that by
the time I master it, my current project is six months behind. I'd much
rather use a set of small, tight point libraries and provide my own glue
(I'm good at glue, I've been doing it for years). That's why I'm using
Hibernate and Tapestry right now instead of JBOSS or the ultimate
uber-platform .NET.

***

My Mantra is "Less Is More". I want less code, less XML, less HTML. 4.0 is
headed in the right direction by that measure. Simplcitiy, Consistency,
Efficiency, Feedback. 4.0 is an improvement on 3.0 in terms of all four
principles. Refactoring around HiveMind is largely the reason.

*** PMC That's great and I'm all for simplicity as well (its sort of like
being for mom and apple pie). For me as a user though simplicity hinges on
how easy tapestry is to implement, rather than how easy it us for its own
developers to work on or unit test.

On an academic level I'm *highly* sympathetic to the desire of backend
developers to refactor and rewrite so they can have a clean codebase going
forward. I've done it myself on various commercial products I've written.
The selfish part of me though doesn't get anything out of codebase cleaning;
it makes the developer's life easier going forward without doing much for
the user base.

I've actually bitten the bullet a couple of times on commercial apps and
done huge rewrites (usually between 2.x and 3.0 versions) and I've been
burned by my user base virtually every time.

Them: "You mean I waited two years for this!"
Me: "Yeah, but I rewrote the whole thing in java, got rid of that 1980
legacy forking architecture that never quite worked right on XP, switched
the API from that proprietary crap we were using to web services and reduced
the code base by 20%".
Them: "So let me get this straight, we went from a 4 Meg c language client
to a 40 MB JVM install, the product takes six times as long to boot now
because the JVM has to start up, I have to rewrite all my external apps that
connect to the system, and all that to get back to a system which does
*exactly the same thing*".

Which isn't to say that you're necessarily going to make the same mistakes I
did on that particular app (failing to provide backward compatibility for
the APIs was a big one), or that Hivemind won't allow lots of cool new stuff
that'll make me jump for joy. Right now though I haven't yet heard of what
the Hivemind integration is going to do for me as an end user, so I have a
fear, based on my own experience, that it's going to be a "developer"
release.

***

If you want whizz bang components right now, go write some. Tapestry has had

the necessary support, server-side and client-side, including dynamic
JavaScript, for quite some time now (2 - 3 years). There are limits to what
can be packaged with Tapestry proper, due to licensing, so I think the
really interesting (Ajax) components are always going to be a seperate
project.

*** PMC

The whole point of a gui framework though is to speed up my development
effort. More and better components = faster cleaner development of my apps.
If I have to spend a lot of time writing components in order to "flesh out"
a framework, I'm not getting the kind of value out of it I could be. For my
selfish purposes, I'd rather see a rock-solid "timestamp" field that is a
datepicker+time picker than all sorts of back-end goodness. I'd use a
timestamp field all the time.


***

The "take my ball and go home" argument doesn't carry much weight either.
I'd really prefer to see some encouragment here. I've invested years of my
life, and the equivalent of $200,000+ in lost wages, into Tapestry. When I
see messages that accuse me of some kind of intellectual self-indulgence, it

can be pretty de-motivating.

*** PMC

I hope I'm not coming across that way and if so I apologize (really). As a
fellow developer, I'm more than aware of the scope of time and effort that
must have gone into Tapestry so far and frankly I'm really impressed with
both the work and a lot of the ideas encapsulated in the code. It's made me
rethink a number of my web design paradigms (in a good way).

I think what you're seeing though is the gradual rise of the user base
(that's us) a real sizeable group. Broadly, users act sort of like a boat
anchor for a product because we could care less about the backend. All we
care about are features, features, and stability.

So perhaps you're a bit of a victim of your own success. As more and more
people use the product, it's going to be harder and harder for you to make
major architectural changes without either A) breaking some existing code or
B) disappointing your user base who'd rather see your valuable time go
towards something they can use on a daily basis.

--- Pat





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Erik Hatcher
In reply to this post by Gregg D Bolinger

On May 6, 2005, at 11:23 AM, Gregg D Bolinger wrote:
> I am hoping that IoC still remains a developers option when using
> Tapestry.

Of course it is.  How could it not be?  You could use Spring in  
Tapestry 3.0 just fine, and there is nothing any Java project could  
do to prevent you from using Spring (is there?).

>   How hard will it be to use Spring instead of HiveMind if I
> want?  Is that even possible?

You will use Spring just like you always do... and it will actually  
be even easier than ever before *because* of HiveMind facilitating it  
with custom prefix handling and other more flexible infrastructure.

> BTW - I've taken a look at Wicket and while it does look like a
> Tapestry clone, it is coming along quite nicely.  If I am forced to
> use HiveMind with the new Tapestry, I'll use Wicket. :)

Well, I guess we've lost you to Wicket then.  "forced" is such a  
strong word.  You were "forced" to use the built-in IoC-like stuff in  
Tapestry 3.0 and you didn't complain.  Tapestry 4.0 provides a much  
more pluggable infrastructure based on HiveMind.  HiveMind is  
integral to it, but you may not ever see it specifically except for  
the JAR file in WEB-INF/lib.  The same configuration that you're used  
to in 3.0 will work in 4.0, and it will allow even more flexibility.

You won't be "forced" to use HiveMind as an IoC container for  
anything other than Tapestry internals (again, you may not even see  
it explicitly).  You can use whatever you want for your business/DB  
integration, Spring included.

     Erik


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Gregg D Bolinger
Erik, thank you for clarifying things for me.  I'm not lost to Wicket.
 I was just making a point. ;)

Thanks again.

Gregg

On 5/6/05, Erik Hatcher <[hidden email]> wrote:

>
> On May 6, 2005, at 11:23 AM, Gregg D Bolinger wrote:
> > I am hoping that IoC still remains a developers option when using
> > Tapestry.
>
> Of course it is.  How could it not be?  You could use Spring in
> Tapestry 3.0 just fine, and there is nothing any Java project could
> do to prevent you from using Spring (is there?).
>
> >   How hard will it be to use Spring instead of HiveMind if I
> > want?  Is that even possible?
>
> You will use Spring just like you always do... and it will actually
> be even easier than ever before *because* of HiveMind facilitating it
> with custom prefix handling and other more flexible infrastructure.
>
> > BTW - I've taken a look at Wicket and while it does look like a
> > Tapestry clone, it is coming along quite nicely.  If I am forced to
> > use HiveMind with the new Tapestry, I'll use Wicket. :)
>
> Well, I guess we've lost you to Wicket then.  "forced" is such a
> strong word.  You were "forced" to use the built-in IoC-like stuff in
> Tapestry 3.0 and you didn't complain.  Tapestry 4.0 provides a much
> more pluggable infrastructure based on HiveMind.  HiveMind is
> integral to it, but you may not ever see it specifically except for
> the JAR file in WEB-INF/lib.  The same configuration that you're used
> to in 3.0 will work in 4.0, and it will allow even more flexibility.
>
> You won't be "forced" to use HiveMind as an IoC container for
> anything other than Tapestry internals (again, you may not even see
> it explicitly).  You can use whatever you want for your business/DB
> integration, Spring included.
>
>      Erik
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Erik Hatcher

On May 6, 2005, at 2:10 PM, Gregg D Bolinger wrote:

> Erik, thank you for clarifying things for me.  I'm not lost to Wicket.
>  I was just making a point. ;)

Like my kids saying "I'm not going to clean up my room unless I you  
let me eat some candy first".  Lousy way to make a point, and it  
doesn't work here.  Howard and I will happily use Tapestry even if  
the rest of you all went home.

     Erik
 
 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Gregg D Bolinger
Well, these kinds of statements don't help your cause.  I apologize
for the making a poor comment.  I'm glad that Howard lost over
$200,000 so that you and him can use a framework.  There is a
community out here you know.  And we like Tapestry.  We have a right
to question it's future development.  If you don't want us to have
that right, make it closed source and sale the framework to those that
want to buy it.

Gregg

On 5/6/05, Erik Hatcher <[hidden email]> wrote:

>
> On May 6, 2005, at 2:10 PM, Gregg D Bolinger wrote:
>
> > Erik, thank you for clarifying things for me.  I'm not lost to Wicket.
> >  I was just making a point. ;)
>
> Like my kids saying "I'm not going to clean up my room unless I you
> let me eat some candy first".  Lousy way to make a point, and it
> doesn't work here.  Howard and I will happily use Tapestry even if
> the rest of you all went home.
>
>      Erik
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Brian K. Wallace
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Perhaps we've lost focus a bit here. I believe everyone has made a point
- - some better in a community situation than others, but all points made.
It would be better if we could disolve this thread and continue with a
basis of problems noted, areas to be addressed, and knowledge that this
is a community that's relatively new and still strong. Everyone here
listens. Let's get back to user/design/code issues, please.

Gregg D Bolinger wrote:
| Well, these kinds of statements don't help your cause.  I apologize
| for the making a poor comment.  I'm glad that Howard lost over
| $200,000 so that you and him can use a framework.  There is a
| community out here you know.  And we like Tapestry.  We have a right
| to question it's future development.  If you don't want us to have
| that right, make it closed source and sale the framework to those that
| want to buy it.
|
| Gregg
|
| On 5/6/05, Erik Hatcher <[hidden email]> wrote:
|
|>On May 6, 2005, at 2:10 PM, Gregg D Bolinger wrote:
|>
|>
|>>Erik, thank you for clarifying things for me.  I'm not lost to Wicket.
|>> I was just making a point. ;)
|>
|>Like my kids saying "I'm not going to clean up my room unless I you
|>let me eat some candy first".  Lousy way to make a point, and it
|>doesn't work here.  Howard and I will happily use Tapestry even if
|>the rest of you all went home.
|>
|>     Erik
|>
|>---------------------------------------------------------------------
|>To unsubscribe, e-mail: [hidden email]
|>For additional commands, e-mail: [hidden email]
|>
|>
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: [hidden email]
| For additional commands, e-mail: [hidden email]
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)

iD8DBQFCe7bwaCoPKRow/gARAnLTAJ9v5tOdq4Cie2lWuYL1wdNcikic+gCguEOz
vww8o74XhBCJbhAfBCDREXc=
=C3+o
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Nathan Kopp
In reply to this post by Patrick Casey
"Patrick Casey" <[hidden email]> wrote...
> I've actually bitten the bullet a couple of times on commercial apps and
> done huge rewrites (usually between 2.x and 3.0 versions) and I've been
> burned by my user base virtually every time.
> [clip]
>
> Which isn't to say that you're necessarily going to make the same mistakes
I
> did on that particular app (failing to provide backward compatibility for
> the APIs was a big one), or that Hivemind won't allow lots of cool new
stuff
> that'll make me jump for joy. Right now though I haven't yet heard of what
> the Hivemind integration is going to do for me as an end user, so I have a
> fear, based on my own experience, that it's going to be a "developer"
> release.

True, but sometimes the code gets too messy and too complex to be able to
add the features or change things in the ways the users want.  So, in order
for forward progress to be made, you have to take a moment to pause, clean
things up, regroup, and then start moving forward at full force.  That is I
think what's happening with Tapestry 4.0.  It does seem to be a
developer-focused release, but I've looked at the 3.0x code, and this step
seems necessary if you want to see accelerated progress on user-focused
features.

-Nathan


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

Vjeran Marcinko
In reply to this post by Gregg D Bolinger
----- Original Message -----
From: "Gregg D Bolinger" <[hidden email]>
To: "Tapestry users" <[hidden email]>
Sent: Friday, May 06, 2005 5:23 PM
Subject: Re: Components to fry JSF and all other frameworks

> I am hoping that IoC still remains a developers option when using
> Tapestry.  How hard will it be to use Spring instead of HiveMind if I
> want?  Is that even possible?

Strangely, how come I never hear anyone complaining to Rod Johnson for how
they want to use Spring MVC as web layer *but* without having Spring IoC
container around, because they only want HiveMind for that, not both ?
Rod would probably be puzzled by this strange need no less then Howard....

Let me get this straight because I heard this unreasonable complaint before
about having 2 IoC containers - There is almost always some kind of
container inside some project!
Tapestry 3.0 has it also - in a form of .application file, Extensions,
EngineServices etc... It is the way hw Tapestry 3.0 is built. It was blended
with whole framework so you never considered it as something separated, with
some special name. The only difference now with Tapestry 4.0 is that this
container is separated as new project (HiveMind), and it's something that
Tapestry is built on, same as before, just with difference of being separate
project, with a name.

You should not care how Tapestry is built, you should pick whatever you want
in your project. If it's Spring, so be it. Use it as you always did. The
only thing desirable for IoC frameworks is that they know how to inject
dependencies from one to another, so that wiring of dependencies would be
outside of code, and Tapestry 4.0 offers that in a form of "inject" tag.

-Vjeran



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.5 - Release Date: 4.5.2005


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Components to fry JSF and all other frameworks

t.n.a.
In reply to this post by Howard Lewis Ship
Howard Lewis Ship wrote:

>The "take my ball and go home" argument doesn't carry much weight either.
>I'd really prefer to see some encouragment here. I've invested years of my
>life, and the equivalent of $200,000+ in lost wages, into Tapestry. When I
>see messages that accuse me of some kind of intellectual self-indulgence, it
>can be pretty de-motivating.
>  
>
Howard,

your work - as well as the work everyone else put into tapestry and
hivemind - is truly inspirational, at least by my standards.
I would think that this discussion (among other things) about future
possibilities of improvement is a sort of reward in itself: to see
people react, contribute and exchange ideas about something you created.
I don't see an ambiguous comment here and there as reason enough for you
to frown. :-)

Regards,
Tomislav

--
Tomislav Nakic-Alfirevic
Netgen Ltd. www.netgen.hr
Rudeska 172/3
10000 Zagreb, Croatia
tel.: +385 1 387 97 22
fax.: +385 1 387 97 24


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Moving .properties files

Kuon
In reply to this post by Kuon
After reading the code, I finaly found out that the .properties location
is hard coded to be the same as the .page file.

So there is no way.

I'll put my .properties files in the same folder as the specification,
but I hope in 4.0, there will be a way to change this.

Regards

Kuon


Jiki Seirei wrote:

> Hello,
>
> In my application, I moved the HTML template to
>
> /templates/
>
> instead of
> /WEB-INF/
>
> I added
>
>   <context-asset name="$template"  path="/templates/Home/Home.html"/>
>
> for example to the Home page (I created subfolder with page name for
> localization purposes).
>
> My .page are in /WEB-INF/pages
>
> everything work well and I'm happy.
>
> But for some pages, I want to add a .properties file for message
> localization purposes (like text email, logFile comments...)
>
> It work well if I put the .properties next to the .page, but I want to
> put the .properties next to the .html.
>
> Like
>
> /templates/Home/Home.html
> Home_en.html
> Home_jp.html
> Home.properties
> Home_en.properties
> Home_jp.properties
>
> and so one.
>
> Any idea?
>
> Regards
>
> Kuon
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]