IF you mean WebContext : http://localhost:8080/JFly
If you ask the reason why I gave this links is about I solved the css with jar problem reimplementing the redirectors in module JFlyWebCommons, and I plugged pages into an application along with jar. kiuma >----- ------- Original Message ------- ----- >From: Jesse Kuhnert <[EMAIL PROTECTED]> >To: Tapestry development ><[email protected]> >Sent: Thu, 5 Jan 2006 10:36:40 > >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] >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
