Develop from Visual Studio

Thanks for your answer. But with Velocity you miss all the power from .NET / VS. No Debugger, IntelliSense, etc. It feels like going back to classic ASP.  Also it add's another abstraction, and hence a (minor) performance penalty, since the velocity code has te be 'compiled' to something .NET can render.

The only suggested way to develop a widget is through Velocity? There are no other ways?  The user control way is in there a long long time. Meaning all developers switched to the Velocity approach?

For custom development one thing to consider is creation of custom widget extensions, which are nothing more than .NET code that expose functionality to widgets. If your development team is more comfortable with developing inside Visual Studio then you can try to make the widget/Velocity layer as this as possible by putting as much as you can into the extensions and layers below. You may find that this works better for you than trying to do as much as possible in widgets.

Hi Patrick,

Thanks for the clarification on the use of .net based widgets and sorry for the miss-information. I may have got confused when this was discussed a year or so ago. Perhaps I was mixing this up with the Chameleon controls support.

Is is still ok to build widgets in this way then Patrick if it's easier or they already exist (perhaps from an upgrade)? or would you advise that  the widgets are upgraded to use nVelocity so they are 100% upgrade proof? It would be good to know for sure for things like upgrades and how best to approach them.

With regard to putting most of the logic in plugins and being able to step into your plugin and debug in this way is what we tend to do. For me it follows more of an MVC pattern, with very little code and logic in your widget (mostly just mark-up and loops/variables) which is better and easier to maintain than your code being split between in .net controls (where there is a tendency to put bits of code all over the place). It is a shame that there is no intellisense through, hopefully that can be improved in some way in later releases.

thanks

Adam

As stated, I'm new to Telligent development, but I'm stunned by the speed, amount and quality of the responses! Thanks a lot.

Wat we need to archieve is a 'platform', meaning we will have several communities with the same look and feel. So the same widgets on the same place. The only difference should be the stylesheet en our site owners shouldn't be to free to change a lot (in terms of: focus on the content, not on the look and feel).

So the portability of the 'widget-studio' way seems to be the way to go, but I don't want that anybody can change widgets via the widget studio. Changes should be done via our team and all need to be done in Source Control.

For now we extended the 'widget to source control' way, which Adam pointed out. The extension is we strip out the 'body' of all widget XML to create a 'contentScript.html' file, headerScript.html, configuration.xml. With the initialization we will load all widget XML from disk, add the files to the proper way, and 'install' them in Telligent.

This way we have a widget contains of several files, which all have the proper type. So we have Syntax Highlighting and all the good things Visual Studio provides us and hence all under TFS Sourc Control (instead of working within a 'CDATA" block for 1 XML file). We keep the widgets as thin as possible (thanks Dan), the same way we should treat a normal ASCX. The onlyl velocity I foresee is a 'foreach' for repeater kind of stuff. All other things we will do from C# code, so we have all the debugging stuff.
We currently don't support additional CSS/JS files etc which should be placed within the filestorage. But in our case I would like to get rid of them anyway, because I would like 1 main site CSS and  JS file. This for maintenance reasons and it's also a big win for client performance.

Via TFS we can automaticly deploy to our Development environment and stage it for automatic deploying to test, acceptance and production. So the automatic import of the widget XML's comes in fine here!

So we've settled for the widget way, because it seems to be the most preferable and future proof way! We now are going to do the same trick for the theming, so for the most part we decide which widgets are in what place. Site owners should only have limited placeholders for customiziation.

Also if you want syntax highlighting for NVelocity in Visual Studio, check out jonorossi.com/.../cvsi .

The solution for $core_v2_widget.ExecuteFile(‘blah.vm’) is indeed another aproach. It has the same purpose. The main advantage for 'our'  solution would be the widget XML contains all items within the XML. Your solution would load the VM file from disk and execute it (if caching is off), which could be a minor performance penalty. But that shouldn't be noticable for site performance.

So to honestly answer your question: mainly because I wasn't familiar with the Executefile method :) In the end I think this solution is a (bit) cleaner. Mainly because we only want 1 'vm' file per widget, we can maintain a strict naming convention for the inclusion within the widget XML file.

@Alex: Thx! But it doesn't seem to work for VS2012. Is there a solution for VS2012? Occording to this thread is should be possible, but it's never released: http://stackoverflow.com/questions/14714549/visual-studio-2012-colorizer-and-intellisense-for-the-nvelocity-language

To be more technical., we are devvers after all:

/// <summary>
        /// Function called at initialisation stage
        /// </summary>
        public void Initialize()
        {
       
            // Loop through all xml files within the directory
            foreach (FileInfo widgetFile in dirInfo.GetFiles("*.xml", SearchOption.AllDirectories))
            {
                // Only load widget if xml file is same name as its directory (to prevent configuration.xml from rendering as widget)
                if ((widgetFile.Name.Replace(widgetFile.Extension, "") == widgetFile.Directory.Name) )
                {
                    FactoryDefaultScriptedContentFragmentProviderFiles.AddUpdateDefinitionFile(
                        this,
                        widgetFile.Name,
                        GetWidgetConfigStream(widgetFile)
                        );
                }
            }
        }

 /// <summary>
        /// Get Stream for the given xml file with the subnodes replaces by according external files
        /// </summary>
        /// <param name="widgetFile">The widget xml file</param>
        /// <returns>The Stream</returns>
        public Stream GetWidgetConfigStream(FileInfo widgetFile)
        {
            // Create XmlDocument of the provided file
            XmlDocument doc = new XmlDocument();
            doc.Load(widgetFile.OpenRead());

            // List al nodes under /scriptedContentFragments/scriptedContentFragment/
            XmlNodeList elements = doc.SelectNodes("//scriptedContentFragments//scriptedContentFragment/*");
            foreach (XmlNode node in elements)
            {
                // Check if a file exist with the current node name as filename. All files are loaded except .less files
                string[] files = Directory.GetFiles(widgetFile.DirectoryName, node.Name + ".*").Where(name => !name.EndsWith(".less")).ToArray();
                
                if (files.Length > 0 )
                {
                    using (StreamReader sr = new StreamReader(files.First()))
                    {
                        // replace node innerXml by the content of the first file with the node name as filename
                        node.InnerXml = string.Format("<![CDATA[{0}]]>", sr.ReadToEnd());
                    }
                }
            }

            // Create stream from XmlDocument
            using (MemoryStream xmlStream = new MemoryStream())
            {
                doc.Save(xmlStream);

                xmlStream.Flush();
                xmlStream.Position = 0;

                return xmlStream;
            }
        }