XsltDb Future


The goal is to provide a web-based tool to rapidly develop and distribute DotNetNuke modules.

Configurations Explorer

At the moment there are 2 ways of configuration editing.
  • navigate to the module page and click Edit XSLT
  • use XsltDb Rich Client.
I believe that building a configuration tree and providing explorer-like configuration navigation would bring XsltDb development process to the next level. And it also solves the problem when a bug in ASP.NET control properties kill module menu and you can correct your XSLT only using XsltDb Rich Editor.

Package Builder, Versioning And Automatic Upgrade

If I developed a module using XsltDb I can't distribute it as the only way to install it on destination DotNetNuke host is copy & paste. I plan to create a packager that will support building an XsltDb Redistributable Solution - XRS. XRS will provide:
  • Packager. The goal of packager is to put all configurations, SQL scripts, pages of solution in single archive and provide one click installation and upgrade.
  • Version management.
  • Database upgrade (per-version scripts).

You need more? Just write a comment below!

Last edited Jan 2, 2011 at 7:16 AM by findy, version 8

Comments

trapias Aug 20, 2010 at 7:52 AM 
Anton,
so there's no need to compile a dll, great! :-) <br>
Let me try with a different idea: what about implementing ISearchable? It would be nice to have XsltDb modules indexed, and shouldn't be that hard to implement - just to return the module output in GetSearchItems. What about this?

findy Aug 16, 2010 at 1:56 PM 
I plan to implement this function after I create XsltDb "Host settings" where it will be possible to setup extensions.

But now this is possible now using .NET partial classes:

1. create a file, say myfun.cs in XsltDb source folder:

App_Code/XsltDb/myfun.cs

2. add a method to Findy.XsltDb.Helper class as follows:

namespace Findy.XsltDb
{
public partial class Helper
{
public string myfun(string a, string b)
{
return a + "/" + b;
}
}
}

After that you will be able to use

mdo:my-fun('qwe', 'asd')

in your XsltDb configuration.

Or, you can use msxsl:script to create a function inside configuration.

trapias Aug 12, 2010 at 12:25 PM 
An idea: <b>dynamic extensions</b>. What about the capability to build external DLLs to add mdo:* functions? Say I want to add a function to launch a process: I'd build my DLL to handle e.g. a "mdo:processStart" function, put the dll (or dynamic code, e.g. a .vb file) under an xsltdb "extensions" folder and then just use the new method in xslt.