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 > >
