Re: Struts Code Generators
On 7/26/01 7:20 PM, "David Winterfeldt" <[EMAIL PROTECTED]> wrote: > I just saw that Turbine generates code/sql with a > project called Torque (subproject of Turbine). Is > anyone familiar with it to give it a better run down > than the how to on it. I'm still not sure what type > of code it generates (primary key class?). It sounds > like it doesn't generate JDBC and uses xml info to > generate SQL on the fly. I'm not sure if that is > right, but that is the impression I got. > That is correct. Torque has just been split out from Turbine and, though lacking extensive documentation, is functional in a stand-alone mode, as is Fulcrum the service framework. Torque is in part based on the work of Scott Ambler, and I would like to move it more toward Scott Ambler's work and go further and make Torque a JDO implementation. In short I would like Torque to become a transparent persistence layer. Define your object hierarchy, have torque generate everything you need to persist your objects, and use OQL to retrieve a set of objects. Fulcrum is also a stand-alone project now and might save you some time as I see from commits that you guys are working on one too. I'm hoping that Fulcrum will also be compliant with the service framework JSR and I would like JMX enable Fulcrum shortly too. The repositories are jakarta-turbine-torque jakarta-turbine-fulcrum Both repository are laid out in an odd fashion because I just recently separated them from Turbine so they still have turbine package names because I didn't want to break everyone's code. There is only one thing in Torque left to do and than I think Torque would integrate well with Struts: the connection pool needs to be pluggable. I have decoupled everything else but the connection pool still used is the one that is included with Torque which won't work for Struts users or any other users that have their own connection pooling already. Maybe we can work together on Torque and/or Fulcrum to provide persistence and services? I know everyone needs persistence and I have decouple almost every service in Fulcrum from Turbine so they are now useful outside the context of Turbine. Some services of interest may be: BSFService: Bean Scripting Framework service CacheService: I am talking to the author of jpolycache (jpolycache.sourceforge.net) and looking at the commons cache code to replace what is currently there. MimeTypeService SchedulerService UploadService: I know you guys have some code this. SecurityService: Role/Permission based security service TemplatingService/VelocityService: You use JSP but these services are still very useful for things like templated email messages or any sort of generative task. XmlRpcService: Now based on the newly created XmlRpc code at xml.apache.org from code donated by Hannes Wallnoefer. It also now supports SSL. XSLTService: A very simple transformation engine. I know our two groups have traditionally not work much together, but maybe we can change that. There is also the Turbine Developer's Kit (TDK) which could probably be adapted for new struts users. The torque and fulcrum repositories are there if anyone is interested. -- jvz. Jason van Zyl http://tambora.zenplex.org http://jakarta.apache.org/turbine http://jakarta.apache.org/velocity http://jakarta.apache.org/alexandria http://jakarta.apache.org/commons
Re: i18n and Resources
> > I guess it's time for me to jump into the discussion of > > sharing tools :-) If I can I would like to share an > > introspector between struts and velocity. I have a feeling > > that the structs introspector is more complete so I > > would be all for using the struts introspector and it > > can probably be done :-) > > > > It should be feasible to share this. The needs look to be reasonably similar. > > I recently refactored this family of classes to have no dependencies on other Struts > APIs (or even on servlet APIs for that matter). Future enhancement plans include > support for PropertyEditor classes (to let apps customize the property<-->String > translations necessary when going to and from an HTML page) and bean properties that >are > Collections (treating them sort of like indexed or array-based properties), which >would > also benefit both Velocity and Struts. I think it's totally feasible. The idea of a pluggable introspector came up on the vel-dev list a couple weeks ago and that's probably a good idea and if that were done then we could probably share the introspector that's in struts. Velocity has some non-standard behavior like picking values out of Maps, but the introspector proper could probably be shared without much work. If I could get the struts introspector working in velocity maybe we could make that the first tool placed in the org.apache.util package! :-) We'll show them we can play nice ;-) jvz.
RE: i18n and Resources
On Mon, 19 Feb 2001, Schachter, Michael wrote: > Jason, > > I don't see why not, the general idea is the same. Maybe there should be an > org.apache.services package and a separate repository for this sort of > thing? The kind of thing where Turbine and Struts committers can both > participate? There's a discussion on the general list about general tools and frameworks. I guess we should jump in there as there is a discussion in progress! > If there was collaboration, I'd prefer it not to be Struts or Turbine based. > A framework where the community at large decides on how the interface > methods are declared would be a powerful thing, and shouldn't be interfered > with because different design methodologies for web applications cause > different projects to exist. I mean, this is open source. There's a services framework in Avalon and there is one in Turbine. I'm all for melding them into a single framework. There's probably good things about both of them, I am only familiar with the Turbine service framework, but I will be looking at the Avalon way soon! jvz.
Re: i18n and Resources
> Ted Husted (a Struts commtter) and several others are trying to put together a > proposal for a code sharing subproject/repository/something on the GENERAL list > right now -- this sounds like another candidate for code that could be shared once > the infrastructure of the sharing is set up. I've been following it, I've just been quiet :-) > Jason, does this also relate to the DbResources discussion recently on > VELOCITY-DEV, or is that something different? A little different I think: that was more about velocity related tools, or even webapp related tools, versus general tools like a services framework or db connection pool. I guess it's time for me to jump into the discussion of sharing tools :-) If I can I would like to share an introspector between struts and velocity. I have a feeling that the structs introspector is more complete so I would be all for using the struts introspector and it can probably be done :-) jvz.
RE: i18n and Resources
> I hate the fact that the word "service" is so overused, but in this context > it would be an implementation of an interface residing at the request scope > of an application. > > I'm still pushing for a lightweight, application level service framework > within Struts, I'm just working on a proof of concept and some real code > before I go and introduce anything, probably not a great move community-wise > on my part. > > For people unfamiliar with the service framework I'm talking about, > basically it's a set of standard interfaces for common application > functionality such as localization, device detection, object pooling, etc. > The most common functionality would be included with implementations with > Struts, more time-intensive implementations could hopefully be represented > as a set of plugins/adapters for commercial vendor products that provide > that functionality. There is already a functional services framework in Turbine, is there anyway we could work together on this? jvz.
