Tony, In WSM there are always a number of ways to accomplish something. The best one may not be obvious without significant detail. It sounds like this may be true in this case. If you pick the wrong path you may waste time or dig a big hole.
Since templating is natively contained in the product there is a mechanism called Project Variants which are an abstraction of the presentation layer. If you want the same content to be published to existing content that is the first route you should look at. In a ASP.Net MVC Razor View Template, and also to a Twig Template inside a Symfony this could be accomplished with project variants. With a project variant you can set the template that maps to that variant. you can also specify a different publication context. If you want to abstract away from WSM templates I think it may be best to publish content in a format that can be consumed by applications easily and develop against the live set of data. You could for instance publish to XML, JSON or some other similar type. Alternatively or additionally publishing those contents to Delivery Server you can create runtime simple content services for listing files based on taxonomy, personalization, and the page relationships they had in Management Server. Best, Tim On Monday, July 22, 2013 1:59:25 PM UTC-4, Tony Chung wrote: > > Hi Richard, > > Thanks. I've been trained on creating templates (Jian). But I'm lost in > terms of different options for maintaining HTML structure files outside the > code templates. Our first integrator linked XSLT with different XML search > results to generate the HTML that appears on the page. I want to do > something similar, but not XML. > > I was just wondering what other options exist for this type of file-based > templating. > > -Tony > > > > On Sun, Jul 21, 2013 at 4:55 PM, Richard Hauer > <[email protected]<javascript:> > > wrote: > >> Hi Tony, >> >> >> >> In essence it is all code-writing-code. Same with Twig. Same with >> Handlebars. Sounds like you need some training though. The templating >> process in OTWM is very straight forward once you know what all the >> elements do, so figuring that bit out is the necessary first step. >> >> >> >> I will advise but 2 things: >> >> 1) Do your best to avoid pre-execute as it is difficult to debug and >> is rarely necessary to accomplish your task (RD-execute is fine, however – >> while there is a performance impact to SmartEdit and Preview at least >> publishing performance isn’t impacted) >> >> 2) Don’t use a render tag where a normal element/conditional/block >> tag will suffice; there is a performance impact on render tags too, and >> it’s also a bit tricky to debug >> >> >> >> You will find the forums abundant with people willing to help (generally) >> so post questions when you get stuck or something doesn’t make sense. >> >> >> >> Good luck. >> >> >> > -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/reddot-cms-users. For more options, visit https://groups.google.com/groups/opt_out.
