You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Howard Lewis Ship <hl...@gmail.com> on 2011/09/28 02:20:31 UTC
Feedback from Tapestry users
I've had some great opportunities to meet with a wide variety of
Tapestry users over the last couple of months of travel.
Here's a few idea that have come up.
MAKE IT EASIER TO DONATE COMPONENTS & CODE
For a lot of people, the trouble of setting up a component library,
and a Maven repository, and maybe a site to store JavaDoc is a bit
much.
I had a bit of inspiration ... what if we set a few basic ground rules
for creating components & mixins as GitHub projects using Gradle to
build.
Now, someone sends us a GitHub repository URL and a branch/tag name
(for a stable version of their code). We have code running somewhere
that pulls all of these community repositories, runs a build, and
creates an "uberjar" of all the components from all the community
projects, all under a single virtual folder ("community" comes to
mind). There might be naming conventions for things like module names
and a way to find the root package for the contributed library. A
single site would provide the JavaDoc for all such modules, as well as
a Maven repository (perhaps a snapshot repository and a stable
repository, or a Nexus, whatever).
Anyway, that's a thumbnail sketch, but the idea is to create an easy
way that people can develop useful components and get them up on
GitHub and we have a process to aggregate those into a useful library.
Obviously, due to licensing, this could not be hosted at Apache, but
perhaps an EC2 instance or something.
MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
The biggest pain point in Tapestry is Ajax ... what Tapestry does out
of the box is fine, but when you hit the limits (AjaxFormLoop) is
becomes very tangled. The central issue is trying to coordinate the
client-side state with matching server-side state (in the form of the
t:formdata contents). Although I can think of ways to make that a
little more straightforward, on the whole, it's a complexity trap
(each new "solution" just adds more leaking complexity).
There's been a lot of advances in terms of client-side JavaScript MVC
libraries and such; things like backbone.js and friends. I think it
would be very good for Tapestry to start leveraging that kind of
logic, make it very easy to have components on the server side render
markup and JavaScript that shifts responsibility to the client. There
wouldn't necessarily be a Form or TextField at that point, something
similar (like an EditableText) that supported in-place editing, and
management of a context of properties and relationships, with the
ability to control when the update is posted to the server. That would
be an Ajax call that would treat Tapestry more like a restful end
point, sending a JSON payload of property updates that would be
applied to the server-side objects (Hibernate entities and the like)
and stored to a database.
There's a few different interaction models to cover: For instance, in
some cases, clicking on an individual bit of text should cause
in-place editting of just that "field". The change may be posted to
the server on field exit, or via an added button, or may be deferred
until some later point (perhaps triggered by a "form-wide" update
button). Alternately, click a field or a "form-wide" edit button may
transform multiple fields into an editable state all at once, and send
updates to the server when a "form-wide" update button is clicked.
Properly done, this would allow much more "desktop" feeling UIs to be
created. It would allow significantly more complex and reactive UIs
to be created. There would need to be a balance of declarative
behavior with the options to "take the reins" to do some kinds of
operations ... again, I need a lot more time to flesh this idea out.
Ultimately, I see Form/TextField/etc. being used rarely, and only for
simple forms (login page, that type of thing).
Although there are some who think a web application should just be
jQuery on the client side and RESTful endpoints on the server side, I
think the things that make Tapestry useful extend well into "modern"
JavaScript heavy applications. jQuery plugins are nice, but Tapestry
adds composibility, robustness, performance, and other factors that
can streamline development on both sides of the HTTP pipe. We want to
make sure Tapestry stays relevant.
IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS?
Some Tapestry users have reported back that they love Tapestry, and it
feels very natural to them .. but when they show it to other
developers, they others don't "get it". It's hard to pin down ...
what's not to "get"? Fields, methods, templates and events is most of
what you need to know, and that's really not that much. I'm a bit
perplexed by this feedback, because I show Tapestry to a lot of people
who have not seen it (or not seen it in detail) before and most
people's reaction is that's is simple. But again, there's those who
don't "get it" ... how do we identify those people (who may be a
silent majority), how do we identify what they "don't get", and how do
we get them to embrace Tapestry?
--
Howard M. Lewis Ship
Creator of Apache Tapestry
The source for Tapestry training, mentoring and support. Contact me to
learn how I can get you up and productive in Tapestry fast!
(971) 678-5210
http://howardlewisship.com
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Feedback from Tapestry users
Posted by Davor Hrg <hr...@gmail.com>.
on the subject:
"IS TAPESTRY JUST TOO WIERD/ESOTERIC…",
it pretty much can be said for most of other web app building patterns.
It is always difficult to move people from one camp to another.
There are still plenty people not even using Hibernate,
and that can be another big hurdle for Java devs,
and even mor for devs new to java (comming from php or sth else.).
Tapestry tutorial is is same as ever.
by looking at it BeanEditForm looks like cool component, while
at the same time people are dicouraged from using it (especially
when they try to push it's limits.)
While you limit JS tweaking and use tapestry components,
it is rather nice to work with. Even a zone here and there.
The pattern for building web apps fits ok for backend admin interfaces.
Other patterns could be added (like better gwt integration), so one could
build a standard web backend app with plenty admin pages with forms,
and then add a page that is more interactive using GWT (or JQuery).
I would suggest when adding support for other approaches to keep an open
mind, and integrate it even if it means you can not combine classic tapestry
approach on that page with the new one.
For example
- can only use components without javascript
- layout component must not have javascript associated with it
- then use JQuery and RPC on that page (or GWT + rpc)
How much of tapestry internals could be usefull with 0% tapestry JS code
How much of tapestry internals could be usefull with extremly minimal
tapestry JS code (page init + sth crucial)
RANT: (based on T5.2.4)
As soon as I tried use zones in bit more complex situations and
nested a zone insinde one/other all hell broke loose.
- forms submit all buttons (all buttons call onSelected event)
- after changing outer zone, inner one breaks (set id="xx" and t:id="xxx"
seems to fix it)
And the worst part about zones is that for some reason I am forced to
return zone content myself from each event handler.
- why on earth would I return different zone from one defined in link
attribute zone="xxx"
if I want different content I can use delegate just fine.
END:RANT
Davor Hrg
Re: Feedback from Tapestry users
Posted by Geoff Callender <ge...@gmail.com>.
On the last point, "IS TAPESTRY JUST TOO WIERD/ESOTERIC…", I suspect that the most useful thing I've done in JumpStart is something I did only a few days ago - adding a summary of what a page can do and how:
http://jumpstart.doublenegative.com.au/jumpstart/examples/navigation/whatiscalledandwhen
I did it because it occurred to me that I'd never come across such a summary in the Tapestry doco, and it felt like a bit of a revelation, pulling the fundamentals together into perspective!
Of course, maybe it's just me, and maybe I'll look at it in a week's time and think "so what", but if others agree then perhaps something similar should go in the doco?
Cheers,
Geoff
On 28/09/2011, at 5:06 PM, antalk wrote:
> Hi Howard, and other readers,
>
> my 2 cents..
>
> MAKE IT EASIER TO DONATE COMPONENTS & CODE
>
> Yes, but this has been discussed before a couple of times on this
> mailinglist, we definitely a central component / module hub where people can
> download and commit code to. Github is indeed the first candidate that comes
> to mind. We should not forget the Tapestry finder project
> (https://github.com/bobharner/Tapestry-finder)
>
>
> MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
>
> I concur with you that the basic ajax stuff is do-able without too much
> hassle but once you get into the dirty details (multizone updates, adding
> extra javascript calls) its gets quite complicated and you need deeper
> insight into the Tapestry internals. Which is what some users (in our
> company) dont want , they just want it to work and then point me at the
> Jquery stuff... telling me how hard can it be ?
>
>
> Which gets me to the latest point:
>
> IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA
> DEVELOPERS?
>
>
> Yes, maybe for web developers that are used to other web frameworks (jsf,
> flash). I had the opportunity to find and select a web framework for our
> company and stumbled upon Tapestry and i liked it from the start. But other
> developers dont get (or dont want to get) the Tapestry way of thinking.
>
> And I dont really know what it is , because in the end , they can pump out
> web-apps (pages) faster than any other framework...
>
> It just some sort of hurdle you'll need to pass in order to fully embrace
> Tapestry.
>
>
> Good luck with 5.3 ! (im looking forward to it)
>
>
>
>
>
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/Feedback-from-Tapestry-users-tp4847427p4848167.html
> Sent from the Tapestry - Dev mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: dev-help@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Feedback from Tapestry users
Posted by antalk <an...@intercommit.nl>.
Hi Howard, and other readers,
my 2 cents..
MAKE IT EASIER TO DONATE COMPONENTS & CODE
Yes, but this has been discussed before a couple of times on this
mailinglist, we definitely a central component / module hub where people can
download and commit code to. Github is indeed the first candidate that comes
to mind. We should not forget the Tapestry finder project
(https://github.com/bobharner/Tapestry-finder)
MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
I concur with you that the basic ajax stuff is do-able without too much
hassle but once you get into the dirty details (multizone updates, adding
extra javascript calls) its gets quite complicated and you need deeper
insight into the Tapestry internals. Which is what some users (in our
company) dont want , they just want it to work and then point me at the
Jquery stuff... telling me how hard can it be ?
Which gets me to the latest point:
IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA
DEVELOPERS?
Yes, maybe for web developers that are used to other web frameworks (jsf,
flash). I had the opportunity to find and select a web framework for our
company and stumbled upon Tapestry and i liked it from the start. But other
developers dont get (or dont want to get) the Tapestry way of thinking.
And I dont really know what it is , because in the end , they can pump out
web-apps (pages) faster than any other framework...
It just some sort of hurdle you'll need to pass in order to fully embrace
Tapestry.
Good luck with 5.3 ! (im looking forward to it)
--
View this message in context: http://tapestry.1045711.n5.nabble.com/Feedback-from-Tapestry-users-tp4847427p4848167.html
Sent from the Tapestry - Dev mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Feedback from Tapestry users
Posted by Barry Books <tr...@gmail.com>.
MAKE IT EASIER TO DONATE COMPONENTS & CODE
I think this is a great idea but I don't think it needs to be that
complicated. To me the problem is there is no central repository for
module jars so I end up adding a bunch of repositories to my pom file.
All that's needed is a way to submit a repository url to a build
process that just creates jars for each project. Then you just add
that repository to your pom file and you are good to go. It could be
as simple as a Jenkins install that just builds jars from svn or git
and places the jars in a common location. You could have both
snapshots and releases. The build process could also build a
documentation site that describes all the modules so you have one
place to find everything.
MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
There are really two paths here, progressive enhancement and something
more like GWT.
When I'm building public websites I usually pick progressive
enhancement. It took me a while but I finally figured out mixins are
the way to do this. I could never get the hang of Prototype but with
JQuery it is pretty easy to build sites this way. The only real
problem is you can't pass a javascript function back thru an AJAX
request because JSON does not allow functions. The second problem is
it seems pretty easy to end up with a big mess after doing a bunch of
zone updates to the same page but that's just the nature of doing
things this way. Since I've heading down this path I'd say Tapestry is
one of the best frameworks for building this kind of site.
For internal application type sites I've always used GWT with
Tapestry. It's nice using Java on both sides and with Eclipse you can
debug both the client and the server at the same time. The problem is
it's a bit difficult to integrate the two and I've never be completely
happy with what I've come up with. My other complaint about GWT is the
widgets are not very polished and it takes a lot of work to get them
to look nice.
I think the challenge here is deciding what Tapestry wants to be. I
can understand wanting to be JavaScript framework agnostic but I think
this causes two problems.
1. You end up with the lowest common denominator of functionality
2. You have to port every component to every framework or run mixed frameworks
The problem with picking one is you limit the audience to developers
that like Tapestry and whatever JavaScript framework you pick.
Not an easy choice
IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS?
With Tapestry 5 I think it's finally approaching simple things are
simple, difficult things are only slightly harder. Personally I think
implementing the shared component library would go a long way toward
solving this complaint because it would provide examples of how to
solve problems and working code to solve them. The Tapestry-Hibernate
module is great because it just works and I don't have to figure out
how to integrate hibernate with Tapestry. It has some shortcomings but
it's simple and it works for most use cases. I suspect a big part of
the learning curve is the lack of Tapestry-Auth. Almost every app
needs something like that and implementing one that really works is
difficult so the first thing that happens is you get stuck and give
up.
Some suggestions:
1. It would be great if BeanEdit/PageActivation etc could just work
with an Interface because I think this would make building libraries
easier. I could have a User Interface and implement it in Hibernate or
JPA. Then it could also implement what's needed by a Tapestry-Auth
module and they could all work together. Currently you can't do this
easily. Hopefully this would lead to a set of modules that could
interoperate and give developers a big head start when building apps.
A long time ago I used ACS ( now openacs.org ). It was helpful to be
able to just pickup a forum module rather than implementing one. Since
they shared common interfaces the forum module would just work with
the permission module.
2. I know I created a heated discussion with my desire for a Tapestry
object I could inject and have access to multiple services but I still
think it would be useful. It would be nice if you bind an entire
module with something like binder.bindModule(module.class) and then in
your page just say
@Inject
private Module module;
I think this fits nicely with the first idea and I think it would make
things easier for new comers because it clearly defines the API for a
particular module.
Thanks
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org
Re: Feedback from Tapestry users
Posted by Ulrich Stärk <ul...@spielviel.de>.
http://community.apache.org/apache-extras/faq.html
On 28.09.2011 02:20, Howard Lewis Ship wrote:
> I've had some great opportunities to meet with a wide variety of
> Tapestry users over the last couple of months of travel.
>
> Here's a few idea that have come up.
>
> MAKE IT EASIER TO DONATE COMPONENTS & CODE
>
> For a lot of people, the trouble of setting up a component library,
> and a Maven repository, and maybe a site to store JavaDoc is a bit
> much.
>
> I had a bit of inspiration ... what if we set a few basic ground rules
> for creating components & mixins as GitHub projects using Gradle to
> build.
>
> Now, someone sends us a GitHub repository URL and a branch/tag name
> (for a stable version of their code). We have code running somewhere
> that pulls all of these community repositories, runs a build, and
> creates an "uberjar" of all the components from all the community
> projects, all under a single virtual folder ("community" comes to
> mind). There might be naming conventions for things like module names
> and a way to find the root package for the contributed library. A
> single site would provide the JavaDoc for all such modules, as well as
> a Maven repository (perhaps a snapshot repository and a stable
> repository, or a Nexus, whatever).
>
> Anyway, that's a thumbnail sketch, but the idea is to create an easy
> way that people can develop useful components and get them up on
> GitHub and we have a process to aggregate those into a useful library.
> Obviously, due to licensing, this could not be hosted at Apache, but
> perhaps an EC2 instance or something.
>
> MOVE TOWARDS GREATER CLIENT-SIDE FOCUS
>
> The biggest pain point in Tapestry is Ajax ... what Tapestry does out
> of the box is fine, but when you hit the limits (AjaxFormLoop) is
> becomes very tangled. The central issue is trying to coordinate the
> client-side state with matching server-side state (in the form of the
> t:formdata contents). Although I can think of ways to make that a
> little more straightforward, on the whole, it's a complexity trap
> (each new "solution" just adds more leaking complexity).
>
> There's been a lot of advances in terms of client-side JavaScript MVC
> libraries and such; things like backbone.js and friends. I think it
> would be very good for Tapestry to start leveraging that kind of
> logic, make it very easy to have components on the server side render
> markup and JavaScript that shifts responsibility to the client. There
> wouldn't necessarily be a Form or TextField at that point, something
> similar (like an EditableText) that supported in-place editing, and
> management of a context of properties and relationships, with the
> ability to control when the update is posted to the server. That would
> be an Ajax call that would treat Tapestry more like a restful end
> point, sending a JSON payload of property updates that would be
> applied to the server-side objects (Hibernate entities and the like)
> and stored to a database.
>
> There's a few different interaction models to cover: For instance, in
> some cases, clicking on an individual bit of text should cause
> in-place editting of just that "field". The change may be posted to
> the server on field exit, or via an added button, or may be deferred
> until some later point (perhaps triggered by a "form-wide" update
> button). Alternately, click a field or a "form-wide" edit button may
> transform multiple fields into an editable state all at once, and send
> updates to the server when a "form-wide" update button is clicked.
>
> Properly done, this would allow much more "desktop" feeling UIs to be
> created. It would allow significantly more complex and reactive UIs
> to be created. There would need to be a balance of declarative
> behavior with the options to "take the reins" to do some kinds of
> operations ... again, I need a lot more time to flesh this idea out.
> Ultimately, I see Form/TextField/etc. being used rarely, and only for
> simple forms (login page, that type of thing).
>
> Although there are some who think a web application should just be
> jQuery on the client side and RESTful endpoints on the server side, I
> think the things that make Tapestry useful extend well into "modern"
> JavaScript heavy applications. jQuery plugins are nice, but Tapestry
> adds composibility, robustness, performance, and other factors that
> can streamline development on both sides of the HTTP pipe. We want to
> make sure Tapestry stays relevant.
>
>
> IS TAPESTRY JUST TOO WIERD/ESOTERIC/ENLIGHTENED FOR SOME/MANY JAVA DEVELOPERS?
>
> Some Tapestry users have reported back that they love Tapestry, and it
> feels very natural to them .. but when they show it to other
> developers, they others don't "get it". It's hard to pin down ...
> what's not to "get"? Fields, methods, templates and events is most of
> what you need to know, and that's really not that much. I'm a bit
> perplexed by this feedback, because I show Tapestry to a lot of people
> who have not seen it (or not seen it in detail) before and most
> people's reaction is that's is simple. But again, there's those who
> don't "get it" ... how do we identify those people (who may be a
> silent majority), how do we identify what they "don't get", and how do
> we get them to embrace Tapestry?
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tapestry.apache.org
For additional commands, e-mail: dev-help@tapestry.apache.org