Porting JavaScript application into the Silverilight (XML/XSLT/HTML vs. XAML)

We are in the process of porting existing JS application to the Silverlight. You can imagine application as a some kind of document management application: 1.) Documents are stored as XML documents. 2.) Docum开发者_如何学Cents can be of different types. Document types can be added without source code modification (everything is in the DB or FS). - Each document type has different form for editing documents. - Each document type has different form for viewing documents.

Edit and view forms are generated from XML document (and XML schema) using a single XSLT and CSS file. Forms between document types can be very similar or very different. Some may contain bullets, auto-numbering (of some elements), borders, indenting, different font-styles, line breaks..., some may not.

Now, the question :) I am not sure how to port this functionality into the SL. I see two basic options: - to create one universal generator for editing forms, and one universal generator for view forms - to create generator for editing forms, and generator for view forms for each document type (the system which we have now)

For the first option I think that I should "invent" some metadata file which will tell how to generate (style) forms. Because we have to support many different styles I think that this would be like inventing a new CSS.

For the second option I don't know how to create this generators. As I already said, adding a new document type (and new generators) should be done without changing or recompiling the source code, and should be easy as much as it could be (document types are changing daily). We had XSLT in JS, but as far as I know there is no XSLT support in the SL.

And also, I am aware that the generator should probably generate XAML code, not HTML.

We have created a prototype in which we have different generator for each document type. Each generator is stored in different assembly which is then dynamically load into the SL application. But I am afraid that creating this for each document type will be a nightmare.

What do you suggest? Please let me know if you need more info. Thanks!

Cheers!

---

This is a tricky one. I'm going to be difficult now and not actually answer your question but instead suggest an alternate approach: Is it an option for you to handle the XSL processing on the server and then just load the generated XAML into Silverlight through a web service method? Or perhaps even keep the XSL processing in your current Javascript code and just call those js methods from Silverlight.

As for the editing of the XML document, I think it will be even trickier. Generating the form should not be too complicated, assuming that you manage to solve the whole XML -> XSL -> XAML problem. But I cannot think of a good way of getting the values that the user enters into that generated form back to the XML document. Silverlight does support Linq to XML, but those queries are always compiled, which I think you want to avoid. I guess Silverlight in its current version just isn't very well suited to this sort of thing.