Context?
On 1/5/06, Andrea Chiumenti <[EMAIL PROTECTED]> wrote: > > 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] > >
