Ok, finally I setup my cvs: all, JFly source code will be deployed with an Apache Licence:
To get jfly: CVSROOT=:pserver:[EMAIL PROTECTED]:/jfly; export CVSROOT cvs login and then get mudules and put them in the same directory: JFly.war JFlyBusiness JFlyCommons JFlyModel JFlyWebCommons JFlyWebComponents JFlyWebUsers You need to create a jfly db: currently I'm using postgresql 8.1 so the scripts ar for that db. After having created a jfly user (pwd jfly) execute the script you can find in JFlyModel/scripts/db/rebuild.sh then in order with Ant build modules (remember to change maven.ibiblio.url variable you find in file ibiblio.properties of each module root dir): JFlyCommons JFlyModel JFlyBusiness JFlyWebCommons JFlyWebComponents JFly.war JFlyWebUsers The final war is located in JFly.war/dist but it make more sense to use JFly in exploded form (root dir is JFly.war/JFly) so that you can easily add new modules to it. Feel free to contact me for any problem or if you have any suggestion for improvements or correction. (For the lateral menu I want to make it pluggable too using Hivemind, so that each module can bring its own submenu to ad to JFly application). cheers, kiuma On Thu, 2005-12-29 at 09:35 -0500, Jesse Kuhnert wrote: > That sounds very interesting. I'd love to see what you have done. > > On 12/29/05, kiuma <[EMAIL PROTECTED]> wrote: > > > > Hi! > > > > I'm playing with tapestry and tacos to build an application framework > > (actually I don't know how to correctly define it). > > Basically it's a modularized application having a set of reusable > > components like ajax search list, frame decorators, pagers, etc. > > > > If you want a preview I could post the entire source code (or even I could > > give an access to my site). > > > > I've redefined pager and asset encoders and do I was able to bring thing > > like tacos initialization and definition into these 'plugins'. > > > > If you are interested for a preview let me know. > > > > Anyway when things will a bit cleaner I think I'll open a new project on > > sf. > > > > Ceers, > > kiuma > > > > >----- ------- Original Message ------- ----- > > >From: Jesse Kuhnert <[EMAIL PROTECTED]> > > >To: Tapestry development > > ><[email protected]> > > >Sent: Thu, 29 Dec 2005 09:12:41 > > > > > >Thanks for all the feedback everyone has given so > > >far, it's a lot easier > > >than trying to think of all the scenerios myself ;) > > > > > >Here is what is currently implemented, which is > > >basically a hivemind > > >configuration point: > > > > > ><configuration foo..> > > ><unprotected-resource > > >contains="/net/sf/tacos/ajax/components/.*.js" /> > > ></configuration> > > > > > >I like the idea of making people specifically > > >unprotect things themselves, > > >because then we don't have to be liable for anyone > > >getting hax0red. The only > > >issue I have with the per asset idea is that it > > >breaks my own use-case, > > >which is a directory structure looking like: > > > > > >/net/sf/tacos/ajax/dojo/dojo.js > > >/net/sf/tacos/ajax/dojo/src/bootstrap.js > > >/net/sf/tacos/ajax/dojo/src/etc.... > > > > > >To get around the only major haxor flaw that I can > > >see, which is using > > >../../ to move around the paths we could go with > > >something more like: > > > > > ><configuration foo..> > > ><unprotected-resource > > >path="/net/sf/tacos/ajax/components/" > > >contains=".*.js" > > >/> > > ></configuration> > > > > > >We can then use this base path information to > > >validate that whatever > > >resource they are requesting really is contained by > > >the base path. This > > >would add a level of protection to a lot of obvious > > >mistakes people might > > >make. > > > > > >What do you guys think? > > > > > >On 12/29/05, Ron Piterman <[EMAIL PROTECTED]> > > >wrote: > > >> > > >> I just had a thought about RE and the > > >unprotecting, which doesn't make > > >> me very happy. > > >> REs are very tricky, and depending on the code > > >you use, > > >> - say you unportect RE '*css' > > >> - say you don't have $ at the end and don't match > > >the whole expression > > >> - say some one gives along > > >'org\a.css\..\..\..\WEB-INF\' and so forth... > > >> > > >> I know I am very paranoid, but I think it comes > > >from internet reality... > > >> > > >> What about taking another strategy and making > > >unprotection on a > > >> 'per-resource' strategy, using the xml. > > >> > > >> Say we add an attribute to the <asset, called > > >unprotec. > > >> When tapestry processes the XML, the resource > > >will get unprotected, once > > >> (since tap. processes the xml once), for the > > >whole application? > > >> > > >> so you define > > >> > > >> <asset ... unprotect="yes"/> > > >> > > >> this would be better also because it brings the > > >usage (which relies on > > >> unprotection in some cases) and the unprotection > > >itself very close > > >> together. > > >> > > >> Cheers, > > >> Ron > > >> > > > > --------------------------------------------------------------------- > > 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]
