VF for XML?

This hasn't been asked since early this year, but does anyone else want to integrate eWebEditPro+XML into Teamsite? Preferably have IWOV offer this feature.

We are starting to look at common web/print components and this would really help.

I'm a little disappointed about the Windows-dependency, but it's not a big deal - but I do need the ability to provide WYSIWYG xml docs.

As an alternative does anybody (like IWOV people on this forum) know if it would be possible to do our own integration with TS 6.0 and WebEditPro+XML?

Thanks in advance,

M.

Find more posts tagged with

Comments

Migrateduser

I am not sure what the difference is, but for my previous project we published all templated content as XML instead of HTML and VFE was not a problem once we configured it for XHTML (it still defeats some of the goals of templating, let's users create wacky pages, doesn't work for linking to content in a portal environment, generates messy or unnecessary code, etc., so we seriously limitted what could be done with it). What additional value does eWebEditPro+XML provide?

MaryE

If you look at the Ektron site, the main feature is it takes generic XML - so you can apply style sheets or validate against schema and or dtd, so it's more generic.

I've also been considering just "insisting" our writers use XHTML, but they have developed their own DTD over the years they have gotten used to - but for page "snippets". Additionally, with print, there's mumbling about XSL-FO which appears to be slightly different than XHTML, but I still haven't figured out if the two play together.

I was also hoping that it helps with having XML within and XML template, in that it can be validated independently of the template DTD, yet be stored for use in other templates that reference it.

Why use a template at all? I guess there's a need to consolidate, or aggregate XML into larger pieces. If IWOV would give me a warmer feeling about Team XML, I might consider that as an alternative. Then I would like a WYSIWG editor like Ektron (not too high end), so we come full circle.

M.

Migrateduser

I know what you're talking about with coming full circle. Many customers I have worked with who were familar with the full control and reusability provided by tools such as ASPX, etc. before implementing TeamSite would prefer to build data capture forms with the more standard tools than with TeamSite templating and to store the content directly in a database or XML schema of their choice. A custom data capture solution would let you embed the WYSIWYG tool of your choice (such as the one you are looking into). I think TeamSite Templating has one main item of value: it theoretically makes it easier for non-technical business users to contribute content. Developers generally prefer to use XMLSpy or similar tools than data capture forms anyway. If you have only technical developers contributing to the site, coming up with a DTD for your content and using offline tools might be an appropriate solution (though it can be hard to make a case for this to management after they buy Templating).

I think you should be able to run any XML through an XSL to generate the XML in FO format, so the primary storage format should not be too much of an issue.

Sorry I don't have anything to help. I have never even looked at TeamXML - I have enough issues with the Interwoven products I am already responsible for. I highly recommend minimizing use of presentation templates in favor of XSL - I prefer to have the TPL just reformat the DCR XML into a more usable XML and then have XSL on the front-end generate the presentation. This way I don't have to regenerate, workflow and/or deploy every page if something global changes (like the copyright date in the footer, look and feel change, etc.).

MaryE

Ironically it is the non-techinical folks who have come up with using XML for their content (e.g. writers use a tag like editor for writing). So we have two user groups - those who want raw XML and those who want Word-like functions. Hence my original interest ...

M.

gzevin

well, I could think of a CGI callout with a different Ektron instance. The only things is whether Ektrom will support two different activex's on the same client machine

Greg Zevin, Ph.D. Comp. Sc.
Independent Interwoven Consultant/Architect
Sydney, AU