On Sat, 26 Feb 2011 16:41:46 -0300, Jonathan Barker
<jonathan.theit...@gmail.com> wrote:
The documentation has improved immensely, and the quality of help on the
list is amazing. This has not been a single-guru project for quite some
time :-)
Thanks you for saying that. Tapestry hasn't been a one-man shown for at
least a couple years and some people still say it is.
I routinely get bitten by something related to whether I'm managing a
service with Spring, or Tapestry-ioc. More specifically, when Spring
services depend on Tapestry services. Things are getting better on this
front.
My approach with Spring has always been to never have Spring beans depend
on Tapestry services.
Select models. Mostly, this problem has gone away for me because I use a
chunk of code from the wiki that I know you don't like :-)and I agree
with your points.
T5.2.4's SelectModelFactory is very good and easy-to-use solution for
that. For ValueEncoders, Tapestry-Hibernate provides an out-of-the-box
solution. Even if you're not using Tapestry-Hibernate, it's simple to
create a single ValueEncoder implementation that can be reused for many
entity classes.
However, it works, it has allowed me to do some funky stuff
with augmenting lists (where I need to preserve an original selection
even if it is not in the currently available options), and I don't have
high
volumes to deal with. It would not be good for inclusion in Tapestry
however.
I'm curious to see your code, specially the augmenting stuff. :)
Recently, I've done a couple of simple Facebook apps. I needed to
generate absolute URL's (including http://server.domain/) for assets.
There was an option tapestry-force-absolute-uris, and I've contributed
my own
BaseURLSource before to handle some development vs. production switches,
so I thought that would cover it. Unfortunately, I found (after looking
at
Tapestry source) I needed to override the AssetPathConstructor to get the
right URLs for my image files. So, it's great that I could do it, but
that would not be nice for a newbie. (Note: I see there have been some
changes
with T5.2 but I don't know if they resolve my issues).
This seems to deserve a JIRA. Could you file it please?
I also recently built a validation and import page that includes multiple
progressive displays as each phase is completed. Some move automatically
from one to the next, and others require manual verification (acceptance
of warnings). Cool, and it makes sense to me, but getting the blocks
right,
and making it so that it degrades nicely takes a bit of effort. Perhaps
there's a good example now, but my first attempt at graceful degradation
took some head-scratching.
This looks like a multi-step wizard. I never had to implement one, but it
doesn't seem to be hard to do one with a zone, some blocks and a
@SessionState object with all the edited information. What do you mean by
graceful degradation? Supporting users without JavaScript? As far as I can
see, it would be just a matter of keeping which block to show (@Persist or
page activation context) and use Request.isXHR().
I've always found forms containing loops or grids, or loops containing
forms to be a particular challenge.
I didn't. They just worked for me. Having a registered ValueEncoder for
your edited object seems to be something very important for editing lists
of objects.
In extreme cases, what I'm really looking for
I guess is a DataGrid. I wonder if this is an area where pairing with a
company that sells such a component to build a Tapestry wrapper would be
an idea.
I'm not following you here . . .
We all have our comfort zones. For some, javascript is second nature. I
dread it - probably because of experiences years ago.
It seems to me that JavaScript is a nice language that few people know how
to write code really well (and I'm not one of them. I still have to learn
a lot).
For some, filters,
advice, (insert your favorite design pattern here), are very familiar,
and there have been conversations on the list about the best way to
implement or override a particular piece of functionality.
I think these Tapestry-IoC features aren't more used or understood because
most people aren't used to write AOP code and the Decorator pattern. In
other words: IMHO, most people do not understand the concept, not how to
use it in Tapestry-IoC. In the Tapestry 5.0.5 days, I wrote something
similar to Tapestry-Hibernate in 8 hours with no previous experience in
AOP, and most of the time I spent writing the transaction handling itself.
My wish list?
Multiple database support - there was some great conversation last year
on the list with Tom van Dijk.
He did an incredible job so far. His posts in the dev list about it have
been absolutely awesome. That's part of the spirit of open source: you
have a problem, you have the source, you write something that solves your
problem and contributes it to the community. :)
Transaction management on par with Spring.
That's something I dream of doing some day when I have the needed free
time. Would you join me? ;)
Why don't I ask more questions on the list?
If I can't find my answer in a search, I can probably figure it out
myself in about the same time it would take to generate a simplified
version of
whatever I'm working on to post to the list. Or perhaps I should say
that in formulating an intelligent question, I often answer my own
question.
Cool! :) I'd still like to see these posted in the list, both questions
and answers. ;)
--
Thiago H. de Paula Figueiredo
Consultor, desenvolvedor e instrutor em Java, Tapestry e Hibernate
Coordenador e professor da Especialização em Engenharia de Software com
Ênfase em Java da Faculdade Pitágoras
http://www.arsmachina.com.br
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
