Thanks Michael, you are right, in fact both techniques might come into play. I like the idea of Tapestry where the framework does most of the mundane stuff leaving us to get on with more useful chores.
Coming from a 2GL background (IBMs RPG) I am amazed how long Java app dev takes, and the lack of more sophisticated reusable components (like we see in Swing). I also recall when 4GLs were hip, and really they were either too simple or rather complex and expensive. They only seemed to hit the spot for a niche market. A Tapestry component generator would be very useful, giving us reuse but also flexibility. I'll take a look at Trails and JAG, as I am sure they have some useful concepts - many thanks for these suggestions. I am surprised there are not more tools like this for Java though, and I think some more would be very healthy. I though JAG probably a little heavy for lightweight apps and Trails might be a little restrictive. Something a mix of both ideas and a little inbetween in terms of complexity might fit better. Tapestry plus Spring seems like a great idea, but probably still excessive for the average simple web application, hence my idea of Tapestry + HiveMind. Getting the dev team onboard with Tapestry is a struggle, and more complex frameworks means a lot of learning curve and slower delivery, plus higher price! We are finding Tapestry is more productive than our usual Struts developments as the quality, clarity and simplicity of Tapestry pay off nicely. HLS seems to have really hit the spot. I think HiveMind needs some work on it, I'd like to see that xpooled idea implemented, which steps closer to being useful for CMP, without getting too tricky. John ----- Original Message ----- From: "Michael Campbell" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Thursday, November 24, 2005 4:25 PM Subject: Re: how about a Tapestry app generator > Ahmed Mohombe <[EMAIL PROTECTED]> writes: > > > > Sounds a bit like trails, doesn't it? > > > Nope :). AFAIK The main idea of Trails is NOT to generate code :), > > but to "reflect" what's required, using mostly annotations. > > Let's not fall down on semantics; the OP is working on a project to > come up with an application generator. Code generation is one way of > doing that. So is reflection. They are both means to the same end. > > In that light, it sounds a lot like trails. > > -- > Michael Campbell > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
