We have scenario #2 with the caveat that designer used their own tool to edit templates and the IDE runs in the background so they can check how the web site looks live.
> On Oct 30, 2013, at 7:26 PM, Bob Harner <bobhar...@gmail.com> wrote: > > Previewable templates are a great marketing bullet point, but whether you > use them depends on your circumstances: > > 1) You have no UI designer (i.e., the developers are the designers) -- > there is probably no need for previewable templates. > > 2) You have designers who are willing to use some developer tools (IDE, > build tool, version control) -- there is probably no need for previewable > templates. > > 3) You have a designer and he/she is unwilling to use developer tools: use > previewable templates. > > My projects have been mostly in the first category. > > > On Wed, Oct 30, 2013 at 6:55 PM, Geoff Callender < > geoff.callender.jumpst...@gmail.com> wrote: > >> Good helpful responses, thanks, but I'm surprised how broad the range of >> opinions is! >> >> Thiago is passionately in favour of putting in the effort to be >> preview-able, while others feel that it's not worth the effort. Are there >> any more opinions out there? >> >> Cheers, >> >> Geoff >> >>> On 30/10/2013, at 6:04 PM, Geoff Callender wrote: >>> >>> I'm trying so very hard to keep my templates "preview-able" but it's >> getting oh-so-difficult. Is it time to stop trying and just get my web >> designer to use the same development environment as me? >>> >>> When I say "preview-able template", I mean a template coded in such a >> way that a web page designer can open it in a web browser or WYSIWYG editor >> for "preview" and edit. The idea is that it looks close enough to the >> runtime page to be useful, and easily editable. >>> >>> In the past, the techniques that have allowed this include: >>> >>> * Invisible instrumentation (see >> http://jumpstart.doublenegative.com.au/jumpstart/examples/lang/previewabletemplates >> ). >>> * The Remove component (see >> http://jumpstart.doublenegative.com.au/jumpstart/examples/styling/previewablewithstylesheets >> ). >>> * The Content component. >>> >>> But the obstacles have been growing and growing. >>> >>> * These days a page is usually made from lots of complex components. >> None of these will be shown in the preview. >>> * AJAX-busy pages are often made from lots of components that show at >> different times. None of this will be shown in the preview. >>> * Complex components are often made from other complex components. None >> of these will be shown in the preview. >>> * Tapestry's own BeanEdit, BeanDisplay, and Grid, all preview terribly. >> If you put in the work to make them preview-able then you might as well not >> use them. >>> * A field might be replaced at runtime by a PropertyEditor. This will >> not be shown in the preview. >>> * I have to keep the Remove-d stylesheet link in the TML file in line >> with the @Import-ed stylesheet in the Java. >>> * With T5.4, Form labels and fields emit Bootstrap classes at runtime. >> These will not be shown in the preview. >>> >>> So, is it time to accept that preview-able TML is dead, drop the >> techniques above, and teach my web page designer to run the same >> development environment as me? >>> >>> Cheers, >>> >>> Geoff >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
