Go for it - You need to login to edit the wiki, but anyone can create an account to do so via the link at the top-right of the Wiki pages!
On 22/08/05, Gregg D Bolinger <[EMAIL PROTECTED]> wrote: > Thanks Gwyn. That helped clear some things up. Now these need to be > transposed to some sort of documentation on the wicket website. :) I > wasn't sure what the wiki policy was. I know some sites that only let their > developers update/modify the wiki. If I am able to, I can start making > entries when I run across things. Maybe make an "Absolute Beginner" section > for the wiki with this kind of information. Please do - (I'll try & resist the temptation to switch any links to it to http://www.amazon.com/exec/obidos/tg/detail/-/B000007TUR instead!) :-) /Gwyn > > Thanks again and as I come up with other things, I'll be sure and document > them somewhere. > > Gregg > > > On 8/22/05, Gwyn Evans <[EMAIL PROTECTED]> wrote: > > > > Hi & thanks for the input! I'll try & sketch out my understanding of > > some of the things, but hopefully some of the others will jump in as > > needed to correct me or expand... > > > > On 22/08/05, Gregg D Bolinger < [EMAIL PROTECTED]> wrote: > > > Where do resources go? (HTML files, css, etc) - It was easy enough to > find > > > out after I downloaded the examples and extraced the WAR file. Seems > > > simpler to just say "put HTML files in the same package as associated > class > > > files. > > > > Well, as you say, by default HTML files go in the class hierarchy, > > alongside the Java class (of the same name) that deals with them. > > Think of them as templates more than the actual files being served, as > > that might help distinguish them from the resources that are served > > directly, e.g. css files, which belong in the web-app root. > > > > > > > > > > Definition of a home page - It seems that the definition of a home > page is > > > missing. What would seem correct is that the applicationClassName > defined > > > in the web.xml fits this bill. However, I can find no mention of this > > > anywhere. > > > > URL to run "Your first application". Ok, this may seem obvious to > some > > > but for me it wasn't and still isn't for the most part. What url do we > use > > > to start the applications? And where is information about how that is > > > determined? > > > > Well, the typical way it's working out is that your web.xml has a > > single servlet definition, which will be your Application class (which > > typically extends WebApplication). The examples typically map the > > servlet to an "/app/*" url pattern (mainly to allow the option of > > having other parts of the web-app's URL-space to be handled some other > > way) but for ease of use, typically include an index.html to sit in > > the web-app's root that redirects to "/app", thus calling the Wicket > > app. > > > > e.g. > > <html> > > <head> > > <meta http-equiv="Refresh" content="0; url=app"> > > </head> > > </html> > > > > As such, you'd be able to just call the url pointing to the root of > > where the web-app is deployed in the web-server. E.g. (and assuming > > defaults) putting a myapp.war into a server's /webapps/ folder will > > result in the app being loaded at http://<server>/myapp so a call > > there should return the index.html, which will redirect to > > http://<server>/myapp/app. You could of course call that directly, > > but the index.html's there to try & help cover both cases. > > > > Anyway, that calls the Wicket application, but within the Application > > classes constructor, there's have been a call to: > > getPages().setHomePage(<MyHomePage>.class); > > where the app's home page is actually set... > > > > > > Form classes as subclass as WebPage - Is this a) good OO design and b) > > > required? What are the advantages/disadvantages to keeping Form classes > in > > > their very own class? > > > > I'll leave (a) for someone else, but no, I don't believe it's required. > > > > I think that it's partly that the typical use had evolved such that > > the forms are part of the complete page and use the parent page's > > model rather than having their own discrete models. > > > > > > PropertyModel/CompoundPropertyModel - These things > seem > > > confusing to a new user. More so I feel for users coming from a > framework > > > like Struts or Webwork. I was able to understand it a bit better coming > > > from a Tapestry and JSF background, but the documentation on this could > use > > > some work. It seems there is really just enough to confuse people on > how to > > > use them. > > > > Hmm, got to agree with you there! There's a lot going on, what with > > the models you mentioned, along with the DetachableModel aspects, and > > as yet, I've not seen anything that manages to explain clearly what's > > happening where, in terms of what should be used when & how! > > > > > Keep up the good work and please don't take this as a complaint. Mearly > a suggestion. > > > > Not at all - feel free to highlight anything that you think of would > > be worth addressing, either here or on the Wiki. > > > > /Gwyn > > > > > > ------------------------------------------------------- > > SF.Net email is Sponsored by the Better Software Conference & EXPO > > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA > > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > > _______________________________________________ > > Wicket-user mailing list > > [email protected] > > https://lists.sourceforge.net/lists/listinfo/wicket-user > > > > ------------------------------------------------------- SF.Net email is Sponsored by the Better Software Conference & EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf _______________________________________________ Wicket-user mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wicket-user
