Hi Jian, thanks for the feedback. This is good stuff for an FAQ. I response in your points:
Click is targeted at developing web applications and has a strong HTML focus. There is nothing in Click which prevents you from laying out HTML forms by hand, it just provides you the options of having the framework do it automatically for you. There are a couple of approaches you can take here (all with pros & cons): 1. Use Click forms and controls to do all the HTML rendering for you. There are quite a lot of formatting options available, see the click-examples 'Form Properties' demo. http://click.sourceforge.net/docs/examples.html This a 80/20 approach where you can quickly get stuff developed, but may it may not meet your UI design requirements. 2. Subclass the Click form and/or UI controls to customise the rendering. This is a good approach for ensuring a common LAF across your web application, but you have to get your hands dirty in overriding Form class. 3. Use a Velocity macro for a generic layout approach for rendering forms. This is easy to do and gives you good reuse across your web application. An example of this is provided in the click-examples 'Velocity Macro' demo, also see the Form Javadoc http://click.sourceforge.net/docs/click-api/net/sf/click/control/Form.html 4. Layout your forms by hand. This gives you the ultimate control in presentation, but provides no reuse across your web application. The issue of MVC in web applications is an interesting one which I have discussed in http://click.sourceforge.net/docs/why-click.html. For localisation requirements you can used localization strings, both the Page and Field classes have getMessage() methods to return localised strings. Alternatively you can localise your pages and layout forms by hand. regards Malcolm Edgar -----Original Message----- From: jian chen [mailto:[EMAIL PROTECTED] Sent: Monday, 6 June 2005 7:13 AM To: Velocity Users List Subject: Re: Announcement: Click 0.5 Hi, Thanks for sharing this new framework. I briefly looked at your site, and I have one reservation. Web based application is different from desktop based application in which you have to maintain state information. Therefroe, taken a pure desktop based approach to web based app. might not work. Example, the Click framework mentioned: "Click also includes a library Controls which provide user interface functionality." I think it is a problem for taking html construction out of the hands of GUI designer. The controls are completely inside java program, thus, seems like blending the View and Model again together, which I think is against MVC design pattern. Also, It will be a pain you have to keep your controls up to date, as HTML standards change. If the html are maintained by the GUI designer, you, as the programmer, does not need to do anything. Lastly, it might be hard to internationalize the pages. I see you have "OK" button as an example, have you thought about how to internationalize the "OK" string? Just my 2 cents. Jian On 6/5/05, Malcolm Edgar <[EMAIL PROTECTED]> wrote: > Click v 0.5 Web Application Framework is now available. > > Click Highlights: > * Very easy to learn > * Component and Page Oriented design > * Event base programming model > * Automatic form validation > * Page templating > * Velocity page rendering > * Superb error reporting > * High performance > > What to know why anyone would want to build another web application > framework please see > Why Click? at http://click.sourceforge.net/docs/why-click.html > > For the Click Road Map and Changes see: > http://click.sourceforge.net/docs/roadmap-changes.html > > regards Malcolm Edgar > > --------------------------------------------------------------------- > 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] NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Bank or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Bank does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Bank. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
