Re: Insight: T5 is a compiler
I think we're saying the same thing in different ways. "Tapestry compiles the template into a program to generate the content" is a shorter way of saying what you just said. As opposed to JSP which interprets the template character by character. Other systems (WebObjects is one) convert templates into data structures, but I think Tapestry is unique in the way that it builds property accessors into those structures. To me that smacks much more of compilation than interpretation. Pierce > I think the biggest insight I attempt to inject into people is the > component template: It's easy to think about it the way a JSP > operates: working character-by-character. But for Tapestry, the > template is actually a blueprint for building a structure in memory, > and that structure is a program for generating a server-side DOM, and > only at the end is that DOM emitted character-by-character. > > "The string is a stark data structure and everywhere it is passed > there is much duplication of process. It is a perfect vehicle for > hiding information. > -- Alan Perlis > > I interpret this as "strings are bad", they hide information, or make > it more difficult to manipulate. Treating the template as a structure > of objects lets Tapestry do things implicitly that are complex in > other environments. > > > On Thu, Apr 28, 2011 at 9:23 AM, Pierce T. Wetter III > wrote: >> >> I'm job hunting right now which means I sometimes have to explain why I >> chose Tapestry for a web application platform. ( >> http://www.linkedin.com/in/pwetter if your company needs a new Director of >> Web Development ). >> I had an insight yesterday that I thought I would share. Tapestry is a >> compiler. >> That is, Tapestry considers your .tml files and your .java files as just a >> starting point. From that starting point it builds data structures, new >> classes, bytecodes and a host of other cool stuff behind the scenes. That's >> one of the reasons its so fast and efficient as an application framework >> while running. Unlike a lot of other frameworks that are essentially running >> as interpreters, Tapestry runs as compiled code. >> The key insight here is something I've known about T5 for a while: Your >> .java files and .tml files are just the starting point; they're essentially >> declarations that are re-interpreted by T5 to produce a lot of stuff behind >> the scenes. You may think that you have Component.java, which declares a >> class called Component with one or 2 methods, but by the time Tapestry is >> finished with it numerous additional methods and instance variables have >> been added, certain things in your class have been rewired, all kinds of >> cool stuff. Just as a few lines of declaration code imply a whole bunch of >> work by the java compiler behind the scenes, so does a few lines of Tapestry >> code imply a whole bunch of work by the "Tapestry compiler". >>I hope this insight helps people. >> Pierce >> > > > > -- > 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: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > smime.p7s Description: S/MIME cryptographic signature
Insight: T5 is a compiler
I'm job hunting right now which means I sometimes have to explain why I chose Tapestry for a web application platform. ( http://www.linkedin.com/in/pwetter if your company needs a new Director of Web Development ). I had an insight yesterday that I thought I would share. Tapestry is a compiler. That is, Tapestry considers your .tml files and your .java files as just a starting point. From that starting point it builds data structures, new classes, bytecodes and a host of other cool stuff behind the scenes. That's one of the reasons its so fast and efficient as an application framework while running. Unlike a lot of other frameworks that are essentially running as interpreters, Tapestry runs as compiled code. The key insight here is something I've known about T5 for a while: Your .java files and .tml files are just the starting point; they're essentially declarations that are re-interpreted by T5 to produce a lot of stuff behind the scenes. You may think that you have Component.java, which declares a class called Component with one or 2 methods, but by the time Tapestry is finished with it numerous additional methods and instance variables have been added, certain things in your class have been rewired, all kinds of cool stuff. Just as a few lines of declaration code imply a whole bunch of work by the java compiler behind the scenes, so does a few lines of Tapestry code imply a whole bunch of work by the "Tapestry compiler". I hope this insight helps people. Pierce smime.p7s Description: S/MIME cryptographic signature
Re: [ANNOUNCEMENT] tapestry-watchdog 0.0.1 released!
I agree. First off, an announcement is not a solicitation: so·lic·it [suh-lis-it] Show IPA –verb (used with object) 1. to seek for (something) by entreaty, earnest or respectful request, formal application, etc.: He solicited aid from the minister. 2. to entreat or petition (someone or some agency): to solicit the committee for funds. 3. to seek to influence or incite to action, esp. unlawful or wrong action. 4. to offer to have sex with in exchange for money. –verb (used without object) 5. to make a petition or request, as for something desired. 6. to solicit orders or trade, as for a business: No soliciting allowed in this building. 7. to offer to have sex with someone in exchange for money. Second, tynamo, chenille kit, and others are essentially child projects of tapestry. The tapestry users list is the perfect place for announcements of new releases of said child projects. How else would you find out about them? So no worries. The whiner neither knows the proper use of the word solicitation, nor how to automate mail rules. Don't take him seriously. Pierce P.s. In the interest of accurate disclosure I suppose I should note that I have made very minor contributions to tynamo. So perhaps I am biased, but I doubt it as I'm not a registered committer to the project I've merely tried to give back to a project I found useful. Sent from my iPad On May 30, 2010, at 6:47 PM, Patrick Moore wrote: > Keep on making the announcements! I wasn't aware of your project before! > Glad that you are contributing! Just because someone takes offense doesn't > mean you did anything wrong! > > After all, I get offended by people who have the initials "PS" . So > imagine how offend I get with people adding "PS" to their letters. > > > On Sun, May 30, 2010 at 6:43 PM, Kalle Korhonen > wrote: > >> My apologies if announcing Tynamo modules on Tapestry users list >> offend anybody - if community feels that way, we have no problem >> keeping the announcements only on Tynamo lists and site. However, as >> an open source project completely based on Tapestry, I would have >> thought Tapestry users would generally be interested in our releases. >> In any case, "solicitation" feels pretty degrading. It's not like >> anybody's making any money out of this. Suppose a vote is on order if >> there are others who feel Tynamo or other related Tapestry projects >> shouldn't be announcing on Tapestry Users list. >> >> Kalle >> >> >> On Sun, May 30, 2010 at 5:43 PM, Paul Stanton wrote: >>> How do I unsubscribe from tynamo's solicitation without leaving the >> tapestry >>> users list? >>> >>> Kalle Korhonen wrote: Hey all, it's the Tynamo project here again. Just to keep up with releasing something new every month, we are announcing tapestry-watchdog, version 0.0.1! This module got released sometime ago but as a multi-process application that most of the time doesn't do much but needs to deliver when the time comes, we took a bit longer to test it out. tapestry-watchdog is an "embedded watchdog" that sends an email to you right away if something happens to your parent process (we've all seen an OutOfMemoryError right?) Configuring tapestry-watchdog couldn't be any simpler to configure, but read more about it from our tapestry-watchdog guide (http://tynamo.org/tapestry-watchdog+guide). Enjoy, Tynamo Team - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >>
Re: 5.2 xsd problem?
On May 11, 2010, at 10:47 AM, Pierce T. Wetter III wrote: > I'm getting a complaint about my p:else not being in a component after I > refactored some to pull my navigation menus from layout down into a menu > component. > > It works with this header: > > http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"; > xmlns:p="tapestry:parameter"> > > but not with this header: > > http://tapestry.apache.org/schema/tapestry_5_2_0.xsd"; > xmlns:p="tapestry:parameter"> Figured it out. There is no such thing as http://tapestry.apache.org/schema/tapestry_5_2_0.xsd yet, so it confuses the parser. Nor is there a tapestry_5_2_0.xsd at all, just 5.0 and 5.1. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
5.2 xsd problem?
I'm getting a complaint about my p:else not being in a component after I refactored some to pull my navigation menus from layout down into a menu component. It works with this header: http://tapestry.apache.org/schema/tapestry_5_1_0.xsd"; xmlns:p="tapestry:parameter"> but not with this header: http://tapestry.apache.org/schema/tapestry_5_2_0.xsd"; xmlns:p="tapestry:parameter"> bar foo Pierce
Re: How to use a grid with some "null" cells
On May 11, 2010, at 5:59 AM, Claude Dubois wrote:
>
> You put me on the right way.
> It still didn'twork using the tag, so I tried to add a .
>
> My tml looks like that :
>
>
>
> ${user.shop.shoCode}
>
>
>
> Using this method it works well.
>
> Thanks for your help
The problem is slightly different then just being a null. The problem is that
shop is null, so user.getShop().getShoCode() throws an exception. So the
problem is that one step removed from the value to be displayed is a null.
You can deal with this more easily by using the ?. operator.
${user.shop?.shoCode}
?. will stop if shop is null.
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Answering my own JEE6/Tapestry Question [LONG]
On May 6, 2010, at 3:24 AM, Sergey Didenko wrote: > Hi Pierce, > > Could you share what you think of this approach now, 2 months later? Do you > still think it makes sense to combine Tapestry and EJBs (application > server)? Yep, I'm still using it. Simple searches, etc. are done using tynamo-jpa's injection of an EntityManager. For edits, I spawn off a conversational thread that I'm calling the edit tree, that has an EJB with a persistent entity manager. There's one gotcha I've found which is that because I'm looking up the EJB instead of injecting it, after certain exceptions I can end up with a dead reference to the EJB. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Menu nesting problem
Menus are inherently recursive.
In order to generate ours, I need to generate a series of UL and LI tags with
class="current" on the menu for the current page, and class="currentAncestor"
for the ancestors of the current page.
Example:
Top
Level
Second Level
Current Level
To avoid problems with Tapestry and recursion, I figured out I could setup
things this way, if the currentMenu has a list of its ancestors:
${displayMenu.title}
Current
LevelUL>
Problem is that's illegal XML above because I'm looping over open tags, and
then below I'm looping over close tags.
Is there any clever way around this besides looping over everything and then
using a delegate to insert the current menu at the bottom?
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Tapestry/JEE6 developer needed
Hey gang, we need a new Senior Java developer. San Jose, CA or Flagstaff, AZ. http://sfbay.craigslist.org/sby/eng/1691929735.html Send me your resume if you're interested (you'll be working for me). We're also looking for a consultant to help us bootstrap with OFBiz if there's anyone on this list who knows both. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Suggestion: SeleniumOnlyLauncher
On Apr 10, 2010, at 1:32 PM, Ulrich Stärk wrote: > Sounds reasonable to me. Could you please file an issue in JIRA for it? It > might be down though, so please try later if it doesn't work right away. Done. https://issues.apache.org/jira/browse/TAP5-1103 - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Suggestion: SeleniumOnlyLauncher
Following protocol to have my suggestions discussed here.
Suggestion:
Include a class in tapestry-test that only launches Selenium, not Jetty at
all. This lets you run tests where you've launched the application in some
other way (various maven plugins, etc. )
Provided implementation:
public class SeleniumOnly extends SeleniumLauncher
{
@Override
protected Runnable launchWebServer(
String webAppFolder, String contextPath, int port, int sslPort
) throws Exception
{
System.out.println(" webserver start");
return new Runnable()
{
@Override
public void run()
{
System.out.println(" webserver stop");
}
};
}
}
Sample testng.xml:
http://testng.org/testng-1.0.dtd";>
http://localhost:8083/EdenSchemaTool/"/>
Sample pom.xml excerpt:
org.apache.maven.plugins
maven-surefire-plugin
true
src/test/conf/testng.xml
integration-tests
integration-test
test
false
src/test/conf/testng.xml
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Suggestion: Linksubmit should work outside of form...
Problem:
You have a form in a page, and you have navigation off to the side. So
the navigation is outside the form. If someone clicks the navigation, you want
to make sure you get any edits they've made.
Solution:
LinkSubmit could take an id that it would use when outside a form, and it
would generate $('id').submit().
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Suggestion: Add context to loop
On Apr 7, 2010, at 6:29 AM, Thiago H. de Paula Figueiredo wrote: > On Wed, 07 Apr 2010 09:34:21 -0300, Pierce T. Wetter III > wrote: > >> 1. What if the eventlink is nested several layers deep in components? Then >> value has to be passed all the way down... > > The context in the Loop wouldn't solve this problem. The context is only > passed from the event that triggered the event (in your case, the EventLink). > The object is something that the components need, so it must be a parameter > of them. > Another solution is to use the Environmental service > (http://tapestry.apache.org/tapestry5.1/guide/env.html). Oh, darn, I thought it was more like the page context. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Suggestion: Add context to loop
Except in my example, it wasn't the component with the loop that creates the
eventlink, it was the component _inside_ the loop that makes the eventlink.
Adding context to the loop is about encapsulating the information needed at
the appropriate level. At the level of the outer component where the loop is
used, you can choose to encode the context as just the loop index, as a primary
key, etc.
My example was simple on purpose, but imagine a case where its not. Imagine
some sort of complex AJAX widget, or control panel, or complex HTML that
desperately needs to be componentized. If the component also has to know how to
encode/decode the information it uses to display, then its less generic and
tied more tightly to a particular use and project.
> hi pierce,
>
> don't you have the same problem if you
> put 10 eventlinks on your page. how do you
> distinguish them? either you have 10 different
> event links onEventFromC1() or you use the
> context onEvent(String id)... or onEvent(AlmostAnyObject obj)
> having a loop rendering the 10 eventlinks is
> more or less the same.
>
> if your component creates an eventlink
> it should also be able to handle it and
> therefore provide the corresponding event
> handler.
>
> g,
> kris
>
>
>
> Von:"Pierce T. Wetter III"
> An: "Tapestry users"
> Datum: 07.04.2010 14:35
> Betreff:Re: Suggestion: Add context to loop
>
>
>
>
>>> As a new user of tapestry, loop actually bit me because I assumed it
> did this already and was surprised in my event handlers when my value
> binding was null.
>>>
>>
>> Why not passing the current object as the context of the EventLink
> instead?
>>
>> t:context="value.id">
>>
>> public Object onSelect(IdType id) {
>> ...
>>> }
>
> 1. What if the eventlink is nested several layers deep in components?
> Then value has to be passed all the way down...
>
> 2. Now the nested component needs to know about how the value object is
> encoded, which makes the nested component less "generic" and therefore
> less reusable. In my sample, nestedcomponent doesn't know anything at all
> about "value". It doesn't need to! It's job is just to generate a "fancy"
> link. Instead, that knowledge is localized to where loop is used, which
> also happens to be where the event is processed.
>
> Pierce
>
>
>
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Suggestion: Add context to loop
>>As a new user of tapestry, loop actually bit me because I assumed it did
>> this already and was surprised in my event handlers when my value binding
>> was null.
>>
>
> Why not passing the current object as the context of the EventLink instead?
>
> t:context="value.id">
>
> public Object onSelect(IdType id) {
> ...
>> }
1. What if the eventlink is nested several layers deep in components? Then
value has to be passed all the way down...
2. Now the nested component needs to know about how the value object is
encoded, which makes the nested component less "generic" and therefore less
reusable. In my sample, nestedcomponent doesn't know anything at all about
"value". It doesn't need to! It's job is just to generate a "fancy" link.
Instead, that knowledge is localized to where loop is used, which also happens
to be where the event is processed.
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Suggestion: Add context to loop
Suggestion:
Add a context binding to loop that can be used to set the "value" binding upon
link submission.
Why:
As a new user of tapestry, loop actually bit me because I assumed it did
this already and was surprised in my event handlers when my value binding was
null.
Usage Example:
Enclosing Component.tml:
http://tapestry.apache.org/schema/tapestry_5_0_0.xsd";>
${value.name}
NestedComponent.tml:
EnclosingComponent.java:
@Property
whatever value;
public Object onSelect()
{
--- can now do something with "value" because its been set to the same
thing as it was at generate time based on the index value.
}
The "nested component" doesn't have any context, because it doesn't need to
know how to store the loop value.
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why no recursive components?
>> This is a side-effect of Tapestry's static structure approach. A >> component X embedded in the template of component Y is instantiated as >> an object attached to object Y. This instantiation happens once, at >> page load time. >> >> For X to be recursive (to contain an X), we would need to instantiate >> X and as part of that, instantiation another X to place inside the >> first X. To create the second X we need to instantiate a third X ... >> you can see where this goes. >> >> In theory, we could construct the component heirarchy for the page on >> an as-needed basis, but that might cause its own problems (including >> performance issues) and a while different set of lazy abstractions! Ah I get it. So if I nest components A(B(C(D(E, and B(C(D(E))) Then tapestry builds the following components: A A.B A.B.C A.B.C.D A.B.C.D.E B B.C B.C.D B.C.D.E So while I've written only 5 components, I've instantiated 9, and A.B.C is a different component then B.C. Doing that lets you cache things more effectively. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Question about property bindings vs. expansions
Are these exactly the same or is there a subtle distinction between them? Pierce
Why no recursive components?
Just out of curiosity, why no recursive components? I re-implemented my navigation menu using a solution I found on Google, but it would have been a lot simpler if the menu items had been recursive instead having to use delegate stuff that felt very much like voodoo... Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Answering my own JEE6/Tapestry Question [LONG]
I asked before, didn't get a great answer, but I've figured some stuff out
since then, so here goes:
(Note that some of this stuff may be wrong, I'm not an EJB or Tapestry expert,
I'm just trying to weld the two together. (pun intended)).
Q: How can/should I use EJBs/JPA in Tapestry?
A:
Tapestry currently doesn't support EJB injection, however, there's a
tynamo-jpa project that support injecting EntityManager objects in a fashion
similar to tapestry-hibernate.
You can lookup EJBs easily as needed using the EJB3.1 naming convention
though. Between the two, you can actually produce a "best of both worlds"
environment for using JEE6. That is, you can keep pretty light sessions mostly,
but when you need to write data, you can do that via an EJB.
Read-Mostly using tynamo-jpa:
Tynamo-jpa, like tapestry-hibernate, works best with read-mostly
data. The cycle is something like this:
1. Link to page with primary key of entity stored in context
portion of URL, page expects entity object.
2. Tapestry makes a new EntityManager (EntityManagers are
lightweight objects in JPA).
3. Entity fetched from either database or level 2 cache, passed
to Page.
4. Page generates, entities turned back into primary keys, stored
in context.
5. Entity Manager thrown away.
If you need to write data, you can fetch something into memory, modify
it, and then save it using @CommitAfter.
Despite the dramatic language ("throwing stuff away"), the trade offs are
complex because of the various caches built into JPA. Think of it as if the
only thing that Tapestry needs to store in the session is the primary keys that
it can then, via JPA, use to lookup objects via the cache.
So for searching and displaying data, tynamo-jpa does the job. But
there's an assumption there about what most of your data looks like. For
something like a webstore, 90% of the data is read-only catalog data that
should be cached across users. The read/write data is stuff like the shopping
cart, and that's what needs to be stored in the session, not the catalog, and
it doesn't need to be cached so much.
Or consider GMail. When you login to GMail, it has to fetch all of your
mailboxes, but your data doesn't intersect with anyone elses data. So caching
your mailboxes doesn't make sense, and fetching all of your mail data again for
each page may not make sense. What makes more sense is to fetch the data once,
and then keep it around in the session.
Using EJB session beans for read/write data:
EJBs come in 3 flavors: Singleton, which means everyone gets the same
EJB, Stateless, which means they're kept in pools and re-used, and Stateful
which means "one per customer".
Normally, the container manages the distinction for you. Since Tapestry
doesn't directly support EJB injection though, though you can trust Singleton's
to be singleton's, I'm not sure what happens with Stateless session beans. But
that's ok, because in this case, we want a Stateful session bean, because we
want an EntityManager that has data that persists across requests.
This is what mine looks like:
@Stateful
public class SchemaEditEJB
{
//~ Instance fields
/** Information for EntityManager we want injected when EJB is built*/
@PersistenceContext(
unitName = "LocalDB2GlassFish",
type = PersistenceContextType.EXTENDED
)
protected EntityManager em;
//~ Methods
/**
* Static method to lookup our EJB using standardized name spaces
*
*/
static SchemaEditEJB lookupSchemaEditEJB()
{
for (String prefix: new String[]
{
"",
"java:module/",
"java:app/MyApp/",
"java:global/MyApp/"
}
)
{
try
{
Context context = new InitialContext();
return (SchemaEditEJB) context.lookup(prefix +
SchemaEditEJB.class.getSimpleName());
}
catch (NamingException ex)
{
Logger.getLogger(SchemaEditEJB.class.getName()).log(Level.SEVERE, null, ex);
}
}
return null;
}
/**
* Return an entity manager
*/
public EntityManager getEntityManager()
{
return em;
}
/**
* Persist an object
*
*/
public void persist(Object o)
{
em.persist(o);
}
/**
* revert an object
*
*/
public void revert(Object o)
{
em.refresh(o);
}
/**
* Save everything to the database, and throw the EJB away
*/
@Remove
@Transact
Re: LinkSubmit with Context?
On Mar 30, 2010, at 12:46 AM, Kristian Marinkovic wrote: > if you have multiple linksubmit components you can distinguish them > by adding onSelectedFromSubmit1() or onSelectedFromSubmit2() > action handler. > > the linksubmit component does not support a context parameter out of > the box. if you really need it you have to create your own component. > all you need is the code from the linksubmit component + the part of > submit that stores an action into the form that resolves the context > again: > > formSupport.store(this, new ProcessSubmission(name)); Do you agree that this seems like a bug? That linksubmit should support the same set of things as regular submit? Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: LinkSubmit with Context?
On Mar 26, 2010, at 9:06 AM, Michael Gentry wrote: > Maybe try putting your context on the t:form instead of the > t:linksubmit and see if that works. I've never tried it, but seems > like it should work ... Well, what I really want is to be able to tell which of several buttons in the same form that send the same event got clicked, so I want an event handler to be called with arguments... Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
LinkSubmit with Context?
Ok, so I want a button in my form to jump to a new page, but I want to make sure I got the values from the form first. There doesn't seem to be a context binding on LinkSubmit though, though there are on Submit I see. So what's the solution? (5.2-SNAPSHOT solutions are OK). Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Better EJB3.1 integration?
On Mar 23, 2010, at 12:28 PM, Piero Sartini wrote: >> Has anyone done any work on doing better EJB3.1 integration with Tapestry? >> I know that the Jumpstart does it by using a context lookup, and I'm copying >> that pattern right now (though without the service) but I thought I'd ask if >> anyone has gone one better. > > I tried to integrate tapestry-ioc with CDI - which is IMHO the way to > go for EJB3.1. Unfortunately there is no result yet - it is no trivial > integration and seems more complicated than my time permits. > > You should find a thread about it on this list. Yeah, I read through that (Subject was titled "Discussion") but it never reached a resolution that I could see. For now, my solution has been to lazily use lookup() in a SessionState object, then I manually reset the EJB to null. Just seemed to me like it might not be that bad to do something similar in the IOC. It's pretty cool, IMHO. Most stuff: Uses tapestry-jpa module you an I worked on for searching, displaying etc. Multi-page-edit-to-submit: Uses a short EJB that's not much more than a wrapper around an EntityManager for when you want to change stuff. It uses conversations cribbed from jumpstart and has an edit tree so you can do complex nested edits. Of course, I haven't tested it all the way yet, and I lost two days figuring out that the "action" from the submit button comes after all the success, etc. events. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Silly port conflict
On Mar 22, 2010, at 4:57 PM, Pierce T. Wetter III wrote: > > On Mar 22, 2010, at 3:22 PM, Michael Gentry wrote: > >> I don't know what container you are using, but with Jetty, I do something >> like: >> >> mvn -Djetty.port= jetty:run > > It's the self tests in the tapestry T5.2 build, but I'll try that... Cool. > my hudson build now builds and deploys into nexus again. Doh! Spoke too soon. Mostly, jetty seems to run on port , ignoring the above setting. But turns out I'm getting a conflict with selenium on port anyways. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Silly port conflict
On Mar 22, 2010, at 3:22 PM, Michael Gentry wrote: > I don't know what container you are using, but with Jetty, I do something > like: > > mvn -Djetty.port= jetty:run It's the self tests in the tapestry T5.2 build, but I'll try that... Cool. my hudson build now builds and deploys into nexus again. Thanks! - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Silly port conflict
So my Hudson build of Tapestry can't run the unit tests because I already have something running on port 8080. Is there an easy way to change the port? Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Better EJB3.1 integration?
Has anyone done any work on doing better EJB3.1 integration with Tapestry? I know that the Jumpstart does it by using a context lookup, and I'm copying that pattern right now (though without the service) but I thought I'd ask if anyone has gone one better. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Why does nesting break my Ajax?
On Mar 13, 2010, at 6:54 PM, Thiago H. de Paula Figueiredo wrote: > On Sat, 13 Mar 2010 12:20:52 -0300, Pierce T. Wetter III > wrote: > >>> T5 already has some magic elements, a.k.a. directives, such as t:body, >>> t:parameter, t:block, t:content and t:remove. I don't want to >>> introduce magic component types as well. >> >> Agreed, but does it seem unreasonable to have the directives work with >> invisible instrumentation as well? Even if it had to be t:directive="remove"? > > I really like this idea. :) Please file a JIRA asking for it. Ok, filed as TAP5-1053. Pierce smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
>> I think the issue is for someone relatively new to T5, they don't >> know/understand why fails. To >> them it just seems buggy and/or inconsistent. The basic mechanisms >> look the same, but they don't act the same. That causes confusion. > > I agree. I don't use the syntax. Me three. I've been doing web application development for it seems like a century now. The primary reason I'm porting myself from WebObjects to Tapestry is very similar to the reason I originally selected WebObjects. Beauty. Making a beautiful website means working with artists, and it means some rounds of feedback cycles with those artists. So that means something like the invisible instrumentation stuff in Tapestry. All of the other frameworks out there are too prone to merge code with the HTML, resulting in, well, muck. Me and my artist intend to make full use of this, so that mostly, he can pass me HTML he's gotten working in a browser, I can add t:type="foo" chunks to parts of it to make it dynamic, and it's all good. So rather than t:type="foo" being _optional_, t:type="foo" is the _idiom_. That is, the standard way to do things so that your templates look nice, are understandable by artists. When I build components, I take the extra five minutes to turn them into web pages so that they're self documenting... >T5 already has some magic elements, a.k.a. directives, such as t:body, > t:parameter, t:block, t:content and t:remove. I don't want to > introduce magic component types as well. Agreed, but does it seem unreasonable to have the directives work with invisible instrumentation as well? Even if it had to be t:directive="remove"? I'm willing to do the work to make that happen if someone gives me a hint of where I should do that. Though couldn't t:type just match against the list of directives either first or last? Pierce smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
On Mar 9, 2010, at 1:51 PM, Kalle Korhonen wrote: > Luckily, there's t:remove > (http://tapestry.apache.org/tapestry5/guide/templates.html) in T5.1 as > well - I use it all the time for documentation purposes. Yeah, but t:type="remove" doesn't work. smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
On Mar 9, 2010, at 12:15 PM, Robert Zeigler wrote: > t:contnt is what you want. It's not a component, it is it's own xml tag. So, > either: > > > > >stuff you want in here > > > > > Or: > > > > >... > > > > > Former will exclude html + body in the final rendered page. > Latter will exclude html, but include body in the final rendered page. Yeah, so I guess this is a 5.2 feature request then. There's t:remove and t:content, which you can use to make components "previewable". Then there's t:type ="stuff", which surprisingly, doesn't support type="remove", or type="content". Seems like t:type="ignore" and t:type="remove" would be nice, then you could do This is a my cool component. You can use it by... That is, you could put the documentation for using the component in the template for the component. Just a suggestion that it would be cool to extend the invisible instrumentation, one of the reasons I chose Tapestry was the ability to take a page an artist mocked up and turn it into a dynamic page. It would be nice to go the other way more easily. Pierce smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
On Mar 8, 2010, at 6:07 PM, Thiago H. de Paula Figueiredo wrote: > On Mon, 08 Mar 2010 21:14:28 -0300, Pierce T. Wetter III > wrote: > >> So speaking of which, how do you make a previewable component? > > Use the tag. Everything outside it won't be rendered. Ah, so perhaps I should have been using that instead of t:container. I notice that: doesn't work though. Should it? smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
>>
>> Often what happens is that some invaild JS on the client causes an
>> exception, and (for whatever reason) that results in the original
>> event continuing as a full-page (non-Ajax) request. This is where
>> FireBug is your friend. I know it should just work ... what's your
>> browser?
>
> Safari. Hmmm... It's strange that there could be an exception. In researching
> this issue it seems like other people have run into it when nesting,
> something about the id's changing. I don't think the maven quickstart
> Layout.tml includes any javascript, so it must be something about nesting an
> ajax action so deep messes with something.
>
> But I guess I'll look in the log and see if there's an exception.
Ok.
So this was a combination of things:
Noob mistake:
Somehow, I had gotten the idea that when making re-usable components, I
could put tags inside the .tml for the component, and that
Tapestry threw those away, and just rendered the stuff between the body. So
that meant I was adding extra tags everywhere, which the browser was
ignoring, but caused some weird side effects. When I replaced the HTML/BODY
tags with tags, those went away. Of course, now my .tml files are
no longer legal HTML files.
So speaking of which, how do you make a previewable component?
Search form weirdness:
So I had a search form in the page, and the Layout.tml sample file has an
tag with id="search". So the javascript that Tapestry emits (
$('search').activate() ) had a name collision with the LI tag, and so the
javascript code threw an error when activating the search field, which broke
the ajax.
Pierce
smime.p7s
Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
On Mar 5, 2010, at 7:13 PM, Howard Lewis Ship wrote: > Often what happens is that some invaild JS on the client causes an > exception, and (for whatever reason) that results in the original > event continuing as a full-page (non-Ajax) request. This is where > FireBug is your friend. I know it should just work ... what's your > browser? Safari. Hmmm... It's strange that there could be an exception. In researching this issue it seems like other people have run into it when nesting, something about the id's changing. I don't think the maven quickstart Layout.tml includes any javascript, so it must be something about nesting an ajax action so deep messes with something. But I guess I'll look in the log and see if there's an exception. Pierce smime.p7s Description: S/MIME cryptographic signature
Re: Why does nesting break my Ajax?
Ok, so I've figured out I get the error because request.isXHR is false. So why does wrapping the Layout.tml component from the quickstart cause the Ajax request turn into a non-XHR request? > So I'm building a custom component that's a combination of a Grid component, > with a zone that updates so that if you click on one of the items in the > grid, it uses a second component that uses the beandisplay component to > display more detail. > > It works fine when I have the structure: > > Page > > MyComponent > > > This is, you quick on the grid items, and the zone updates. > > But if I wrap the contents of Page with , I get: "A component > event handler method returned the value Block" error. > > > Page > > > MyComponent > > > > My component looks like this: > > > > > > smime.p7s Description: S/MIME cryptographic signature
Why does nesting break my Ajax?
So I'm building a custom component that's a combination of a Grid component, with a zone that updates so that if you click on one of the items in the grid, it uses a second component that uses the beandisplay component to display more detail. It works fine when I have the structure: Page MyComponent This is, you quick on the grid items, and the zone updates. But if I wrap the contents of Page with , I get: "A component event handler method returned the value Block" error. Page MyComponent My component looks like this: smime.p7s Description: S/MIME cryptographic signature
Re: Tapestry 5, JPA and Hibernate
On Dec 14, 2009, at 2:55 AM, Alessandro Bottoni wrote: > Hi All, > I'm looking at the alternatives that are available for building the > persistence layer of a application in Tapestry 5 and I would be happy to > hear your opinion about a couple of topics: > > 1) I see that there is a support library for JPA and JPA2 > (http://kenai.com/projects/tapestry-jpa) but the description page at > Kenai says that the project was started on september 2009 so I wonder: > Is this library already mature and usable, even for production? The project was started then, but piero had been using his library in production for while. Neither tapestry-jpa or taptestry-hibernate are a lot of code. Tapestry-jpa comes in two flavors. All the work is being done on tapestry-jpa2, which is using the new stuff in JPA2 to make tapestry-jpa2 mostly feature complete with tapestry-hibernate in terms of having EntityValueEncoders and a GridDataSource. So: tapestry-jpa: Stable, not going to change, uses JPA 1.0 tapestry-jpa2: Slightly in flux. Has some new stuff which uses JPA 2.0, which is the only way to build some of the things that tapestry-hibernate provided. It wasn't working with EclipseLink a while back due to what looked liked a bug in EclipseLink-2.0-SNAPSHOT, but I haven't tried it recently. It's working ok for me using Hibernate-3.5.0-SNAPSHOT as my JPA persistence provider. > > 2) Is it better to use JPA/JPA2 or Hibernate3 with Tapestry 5? Why? > (I would probably stick with Hibernate but I'm open to suggestions.) I'm kind of a noob, even though I'm one of the people working on tapestry-jpa. Here's my opinion, which may be partially misinformed, hopefully people will correct me as necessary. For both JPA/Hibernate, you have two ways to go: 1. Container-Managed EntityManagers and transactions. By this I mean that you're using @PersistenceContext and such in your classes so that your web application container (i.e. GlassFish) manages the EntityManagers and the transactions. The Tapestry jumpstart uses this approach. Advantages: You can access more than one persistence unit. Possibly the Container can do smart stuff like EntityManager pools? Transaction stuff happens automatically and mysteriously for you. Very much standardized. Disadvantages: No EntityValueEncoder that "remembers" entities in the session by just remembering their primary key. (Though you could make one easy enough I suspect). No GridDataSource 2. Tapestry-Managed 2a. tapestry-hibernate 2b. tapestry-jpa In this case, you're using @Inject to inject Sessions/EntityManagers as needed. You annotate methods with @CommitAfter when you want transactions committed. Advantages: Because you tell Tapestry up front about your single database connection, it can build EntityValueEncoder and GridDataSources that can pull in your objects as necessary. Disadvantages: You can only use one database connection. You have to be more explicit about what does what in your application. You'll have to do one thing for Tapestry, one thing for standalone code. Summary: You can just use the JPA annotations as is with Tapestry, and the container does the work. If you want, you can use tapestry-jpa and tapestry-hibernate. They have a few more features you might find useful, but they lock you into one database connection. Then the Tapestry container is doing the work instead. Pierce The boundaries of my ignorance: While I'm relatively new to Tapestry/JPA/Hibernate, I've been a WebObjects guy for 12+ years now. I'm just now moving into T/J/H because in my opinion, its just now that the existing tools have passed WebObjects which figured out most of these problems years ago. It's just that WO is getting stale, and the containers have gotten better such that its now really obvious that GlassFish/Tapestry/JPA is the best technology out there. But its all relatively new to me. I started working on tapestry-jpa2 because it seemed to me that it was the best way to integrate JPA with Tapestry. Now I'm not so sure that cloning tapestry-hibernate was the right approach. Tapestry-hibernate is an IoC provider to build Hibernate sessions as needed, but the JPA guys already thought of this issue, so why not use the IoC stuff built into the container? That is, I'm starting to think that the existing @PersistenceContext stuff is preferable to @Inject because its more flexible. So what makes more sense is to implement JPAGridDataSource as something that uses the JPA annotations instead, but to do that I have to understand the JPA/Container IOC vs. the Tapestry IOC a bit better, because one problem with @PersistenceContext is that it takes a static string for the name to inject. So JPAGridDataSource would have to be an abstract superclass and you would then h
GlassFish V3 Shipped Today
I was wondering if anyones knows how the directions here change: http://tapestry.apache.org/tapestry5/glassfish.html That is, I imagine that since V3 is more componentized, perhaps the stax and log4j installs are no longer necessary? Anyone done this? PIerce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-jpa needs some advice
On Dec 3, 2009, at 11:20 AM, Piero Sartini wrote:
>> @CommitAfter("unit1")
>>
>> JPA already defines something like this does anyone have an opinion on
>> using @Inject vs. @PersistenceContext("unit1")?
>
> Hard to say, but I would prefer @Inject. I like to know that I am
> working with the tapestry stuff, not in the JavaEE context. Could be
> confusing if we take the same name.
Can @Inject take a parameter? Can @Commit?
>
> For the rest, I would not try to support two PUs until the jpa module
> is more stable and useable. Last time I tried I had still issues with
> the ValueEncoders as well as with the PersistenceStrategy under
> EclipseLink - right now I am running a custom build without these
> features. Didn't have the time to look into them yet.
My memory is a little fuzzy because it was about a month ago, but I had to
switch to Hibernate-3.5.0-SNAPSHOT for those to work, specifically because of
issues on the EclipseLink 2.0 side that were definitely bugs on the EL 2.0
side. I've been planning on switching back to check I just haven gotten to it
yet. All the JPA2 stuff is a moving target remember. If you're using 2.0, you
can't expect it to be stable yet, until about 2 weeks ago, I couldn't do
count(f) from Foo f in Hibernate-3.5.0 and it's still broken in 3.5.0-Beta-2.
>
> I've looked at the broken test cases but was not able to fix them.
> Seems like much better TestNG and EasyMock knowledge than mine is
> needed :/
Yeah, I had the same problem. I know TestNG well enough, but not EasyMock.
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: tapestry-jpa needs some advice
> This has come up recently; the simple idea is that the when injecting
> a Hibernate Session and additional annotation may be present to
> identify *which* session to inject.
i.e.
@CommitAfter("unit1")
JPA already defines something like this does anyone have an opinion on using
@Inject vs. @PersistenceContext("unit1")?
> However, this raises another
> problem ... ValueEncoders and determining which session to use to
> convert from a string id back to an entity. If the same entity can
> appear across multiple PUs, this becomes an intractable problem.
For the same entity in multiple PUs, with JPA 2.0 you can get the Metamodel
from the Persistence Unit to lookup the entity, and you could build a Entity ->
PU mapping. If you want to tweak which mapping gets used by the ValueEncoders,
it seems like then you could just have some way of configuring that.
But I think the 90% case is for loading two different data models living in
two different databases so I wouldn't be rushing to support that.
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Noob: Wishing for a tapestry-jpa like tapestry-hibernate
Oh well, diving in to see how far I can get by just taking
tapestry-hibernate and making a JPA version.
I did the same some time ago. It works for me, but is far from
being complete:
http://bitbucket.org/psartini/tapestry-jpa/
There is a lot of stuff missing, especially the more advanced
tapestry
features - but the core functionalities are working. There are no
tests
available as well. But maybe it is a good starting point.
About your usecase.. it's not possible to use 2 different
Persistence Units
right now. It is configured throught the application defaults like
this:
configuration.add(JPASymbols.PERSISTENCE_UNIT, "yourPU");
Cool, thanks, I'll crib from this into my implementation.
Ok, here's where I'm at:
I took tapestry-hibernate and tapestry-jpa and migrated them
all to JPA terminology. As part of that, I built the following classes:
CompositeEntityManagerFactory
CompositeEntityManager
CompositeEntityTransaction
What they do is take a list of persistence units and produce a
meta- version of each that lets you treat the composite as a whole. So
commit() commits them all, clear() clear's them all, etc.
The idea would be that you could do:
configuration.add(JPASymbols.PERSISTENCE_UNITS,
{"yourFirstPU","yourSecondPU");
I'm now a bit stuck though, because I decided it would be nice if
you could do:
@CommitAfter("yourFirstPU") to only commit in the first PU, while
rolling back the second.
But I can't quite figure out how to get the value from the
annotation to CommitAfterWorker.
There's also a lot of stuff I'm not quite following, so I'm not
totally sure I've implemented it correctly.
Is anyone who knows more about JPA/Tapestry willing to pick up from
where I've left off? I should be closer.
If so I can look into doing a similar thing for hibernate so that
you can access multiple databases via Hibernate.
Pierce
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Noob: Wishing for a tapestry-jpa like tapestry-hibernate
On Aug 26, 2009, at 5:47 AM, Piero Sartini wrote: Oh well, diving in to see how far I can get by just taking tapestry-hibernate and making a JPA version. I did the same some time ago. It works for me, but is far from being complete: http://bitbucket.org/psartini/tapestry-jpa/ There is a lot of stuff missing, especially the more advanced tapestry features - but the core functionalities are working. There are no tests available as well. But maybe it is a good starting point. About your usecase.. it's not possible to use 2 different Persistence Units right now. It is configured throught the application defaults like this: configuration.add(JPASymbols.PERSISTENCE_UNIT, "yourPU"); Cool, thanks, I'll crib from this into my implementation. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Noob: Wishing for a tapestry-jpa like tapestry-hibernate
Why: Because I have two different databases I want to talk to, which either means two session in Hibernate, Hibernate Shards (which would probably need integration work with Tapestry anyways), or JPA with @PersistenceContext(unitName = "database One"), @PersistenceContext (unitName = "database Two"). Oh well, diving in to see how far I can get by just taking tapestry-hibernate and making a JPA version. Pierce - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
