You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Karthik Abram <ka...@neovera.com> on 2005/05/06 01:29:17 UTC
Components to fry JSF and all other frameworks
Checkout componentart.com's product lineup (checkout the demos for the
components) - ASP.NET is the real competition.
I've said it before and I'll say it again - Tapestry 4.0's focus & direction
is, in my opinion wrong. People will use Tapestry if it provides components
of dizzying complexity and capability - not to mention look 'n feel.
Integrating HiveMind sounds like a bad idea - especially since Spring is by
far the more popular framework. Not invented here? Or, a packaging a la
Microsoft?
inflation adjusted 53 cents
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Mauro Sérgio Silva <ma...@automaware.com.br>.
Robert Zeigler wrote:
>Karthik Abram wrote:
>
>
>>Checkout componentart.com's product lineup (checkout the demos for the
>>components) - ASP.NET is the real competition.
>>
>>I've said it before and I'll say it again - Tapestry 4.0's focus & direction
>>is, in my opinion wrong. People will use Tapestry if it provides components
>>of dizzying complexity and capability - not to mention look 'n feel.
>>Integrating HiveMind sounds like a bad idea - especially since Spring is by
>>far the more popular framework. Not invented here? Or, a packaging a la
>>Microsoft?
>>
>>
>
>further decoupling layers, and making "plug and play" more and more
>possible is a bad idea???
>As for the components... componentart.com isn't microsoft, even though
>microsoft provides asp.net... ie, it's up to users and other
>corporations to write, package, and distribute components. I created
>tassel to help with that... in the next few weeks, my schedule will be
>opening up... slightly... and I have some major improvements and
>revampings to tassel in mind (yes, yes, I will finally get around to
>making a more useable user interface. =)
>Anyway... the point is, like ASP.NET, tapestry provides the framework
>and inner-workings to create the components; it's up to you to create
>the dazzling components.
>
>Robert
>
>
>
>>inflation adjusted 53 cents
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
>
>
>
When I talked about taking a look in myfaces components and the menu I
was talking about use these scripst thet are good and tested in many
browsers (the three view is great)... and since they are used in myfaces
they are license compatible with tapestry !!!
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by "t.n.a." <tn...@sharanet.org>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Nathan Kopp <nk...@mailshell.com>.
"Patrick Casey" <pa...@adelphia.net> 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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Components to fry JSF and all other frameworks
Posted by Patrick Casey <pa...@adelphia.net>.
<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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Howard Lewis Ship <hl...@gmail.com>.
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 <gt...@gmail.com> 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 <ka...@neovera.com> 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:brian@transmorphix.com]
> > 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: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> > For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
--
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
Re: Components to fry JSF and all other frameworks
Posted by Vjeran Marcinko <vj...@tis.hr>.
----- Original Message -----
From: "Gregg D Bolinger" <gt...@gmail.com>
To: "Tapestry users" <ta...@jakarta.apache.org>
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
|>For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
|>
|>
|
|
| ---------------------------------------------------------------------
| To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
| For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
|
|
|
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (MingW32)
iD8DBQFCe7bwaCoPKRow/gARAnLTAJ9v5tOdq4Cie2lWuYL1wdNcikic+gCguEOz
vww8o74XhBCJbhAfBCDREXc=
=C3+o
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Gregg D Bolinger <gt...@gmail.com>.
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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Gregg D Bolinger <gt...@gmail.com>.
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 <er...@ehatchersolutions.com> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Erik Hatcher <er...@ehatchersolutions.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Gregg D Bolinger <gt...@gmail.com>.
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 <ka...@neovera.com> 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:brian@transmorphix.com]
> 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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Moving .properties files
Posted by Jiki Seirei <ku...@goyman.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Moving .properties files
Posted by Jiki Seirei <ku...@goyman.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Components to fry JSF and all other frameworks
Posted by Karthik Abram <ka...@neovera.com>.
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:brian@transmorphix.com]
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by "Brian K. Wallace" <br...@transmorphix.com>.
-----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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Components to fry JSF and all other frameworks
Posted by Patrick Casey <pa...@adelphia.net>.
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:musson.michael@gmail.com]
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Michael Musson <mu...@gmail.com>.
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: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Components to fry JSF and all other frameworks
Posted by Patrick Casey <pa...@adelphia.net>.
<snip>
Anyway... the point is, like ASP.NET, tapestry provides the framework
and inner-workings to create the components; it's up to you to create
the dazzling components.
.NET does a lot more OOB than tapestry currently does though. Just looking
at my .net debugger here, the OOB .NET package includes the usual input
widget variants (like tapestry), as well as:
WYSYWIG layout that supports both flow and CSS.p
Data aware grids that support editing in place
A built in datasqueezer feature that means no rewind problems
A default "actionlink" model that just works
Built in banner ad support
And, due to their datasqueezer approach, you can actually use MS's version
of ActionLinks (as opposed to Tapestry where I just don't trust actionlinks
and use only directlinks).
Now mind you I'm currently using Tapestry, not .net, so the advantages of
tapestry (I can read the source, its java so I can use it with hibernate, it
doesn't require I tell my customers to buy IIS, Eclipse is way better than
visual studio) obviously outweigh the disadvantages.
Nonetheless, I think it's a mistake to write off .net as just a framework.
You can write a very spiffy .net web application using only the components
that ship with it. .Net is a framework *and* a component set.
Personally, the single biggest thing I'd like to see resolved in a new
release of Hibernate is to switch to a datasqueezer approach by default so
that users never, ever, have rewind problems.
As a user, I don't see what Hivemind integration is going to do for me.
It'll probably make the developer's lives easier (I'm assuming), but I'd
rather see more components or a resolution to the rewind issues. If it
enables the development team to fix a bunch of other issues e.g. they can
*put* in more components and resolve the rewind issues *because* it's on
Hivemind then I'm all for it, but Hivemind itself is irrelevant to me unless
it's a means to an end.
--- Pat
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
RE: Components to fry JSF and all other frameworks
Posted by Karthik Abram <ka...@neovera.com>.
I beg to differ - the framework's support for building components is still
lacking and the core team would be adding more value by rolling out core
components. I'm not saying plug n play layers is a bad idea. Just because
something sounds good/technically cool/etc. isn't reason enough to do it.
You are right - componentart.com isn't Microsoft - neither is infragistics,
compoenentone, and the list goes on. The point still remains - ASP.NET has
design-time and run-time specs for building components. A worthwhile focus
for Tapestry
-----Original Message-----
From: Robert Zeigler [mailto:robertz@scazdl.org]
Sent: Thursday, May 05, 2005 8:14 PM
To: Tapestry users
Subject: Re: Components to fry JSF and all other frameworks
Karthik Abram wrote:
> Checkout componentart.com's product lineup (checkout the demos for the
> components) - ASP.NET is the real competition.
>
> I've said it before and I'll say it again - Tapestry 4.0's focus &
direction
> is, in my opinion wrong. People will use Tapestry if it provides
components
> of dizzying complexity and capability - not to mention look 'n feel.
> Integrating HiveMind sounds like a bad idea - especially since Spring is
by
> far the more popular framework. Not invented here? Or, a packaging a la
> Microsoft?
further decoupling layers, and making "plug and play" more and more
possible is a bad idea???
As for the components... componentart.com isn't microsoft, even though
microsoft provides asp.net... ie, it's up to users and other
corporations to write, package, and distribute components. I created
tassel to help with that... in the next few weeks, my schedule will be
opening up... slightly... and I have some major improvements and
revampings to tassel in mind (yes, yes, I will finally get around to
making a more useable user interface. =)
Anyway... the point is, like ASP.NET, tapestry provides the framework
and inner-workings to create the components; it's up to you to create
the dazzling components.
Robert
>
> inflation adjusted 53 cents
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
Re: Components to fry JSF and all other frameworks
Posted by Robert Zeigler <ro...@scazdl.org>.
Karthik Abram wrote:
> Checkout componentart.com's product lineup (checkout the demos for the
> components) - ASP.NET is the real competition.
>
> I've said it before and I'll say it again - Tapestry 4.0's focus & direction
> is, in my opinion wrong. People will use Tapestry if it provides components
> of dizzying complexity and capability - not to mention look 'n feel.
> Integrating HiveMind sounds like a bad idea - especially since Spring is by
> far the more popular framework. Not invented here? Or, a packaging a la
> Microsoft?
further decoupling layers, and making "plug and play" more and more
possible is a bad idea???
As for the components... componentart.com isn't microsoft, even though
microsoft provides asp.net... ie, it's up to users and other
corporations to write, package, and distribute components. I created
tassel to help with that... in the next few weeks, my schedule will be
opening up... slightly... and I have some major improvements and
revampings to tassel in mind (yes, yes, I will finally get around to
making a more useable user interface. =)
Anyway... the point is, like ASP.NET, tapestry provides the framework
and inner-workings to create the components; it's up to you to create
the dazzling components.
Robert
>
> inflation adjusted 53 cents
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: tapestry-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-user-help@jakarta.apache.org