When I said about it being bespoke I meant the system as a whole. ie. how many people do you know that could hop into a delivery server project and how many do you know that would be able to step into a .net project and know what they are doing. You would need special training to use DS and get used to the dynaments etc.. With .net I can just get the cms to pass data to controls and .net can do what it wants to it. Also the search engine wasnt great last time I used it (although it does sound like its getting better), using .net allows the client to choose how they want it searched, most of the time they already have a google mini or GSA.
Regarding technical benefits, I know it integrates fairly well but I dont think there are enough benefits on a solution which costs a lot to implement (cost of the delivery server + the cost of someone who knows how to use it etc..) vs doing it in .net which is a free framework, a huge amount of online support, thousands of .net developers to hand and pretty much any code already on google to use. I know in some situations it might be good to use but I havnt come accross one yet which couldnt be done quicker, easier and cheaper using .net. Just thought of a reason to use it, you might be restricted to a unix platform and with DS running on Apache it wouldnt be as much of a pain to get running as it was on an iis box (we had to use isapi rewrite and that had to be run on IIS as we had a number of URLs assigned in a way that Apache couldnt handle). On 30 November 2011 14:28, Tim D <[email protected]> wrote: > I'd disagree, based on definitions, with Tony that Delivery Server (DS) is > more bespoke than a custom built ASP.Net application. It is a domain > specific application though, focused on content centric sites (intranets, > extranets, and public sites). If you want to build a calculator or > Photo-editing application it won't fit the bill. Although it's integration > capabilities may let you expose apps or work in conjunction with apps > written in a more suitable language. > > *Pros:* > Personalization. You can leverage categories and keywords to be passed on > as metadata that will drive business rules for security, teasing premium > content, providing related content, providing personalized content lists > based on interests, and numbers of other scenarios. Personalization can be > expensive (performance wise) so one of the most important parts of scalable > sites with personalization is advanced caching. Delivery Server has > multiple layers of caching natively so we carry forward the baking > mentality of Management Server even into dynamic content delivery, by > baking as much as we can and caching the baked parts. We do this by a > mechanism called Component Cache that allows elements of a page to be > cached independently. This is something other languages don't provide out > of the > box<http://www.devtrends.co.uk/blog/donut-output-caching-in-asp.net-mvc-3>. > > > Integration. SOAP (Web Services), REST (HTTP), Relational DB (RDB - with > connection pooling), Open API are three connectors and a Java API layer > that allow you to integrate with pretty much anything. The first three take > out much if not all the work of stubbing and post processing. The Open API > lets you call any Java library (LDAP, SAP, Peoplesoft, etc...) and return a > text or XML result. You can then render the results into your design. At > the rendering engine in Delivery Server the Web Content and Integration > results. As well authentication means exist so you can establish trusted > authentication with external applications whether you intend the to run as > a portal above DS. > > Search. Once setup this allows for quite easy setup of facets based on > your taxonomy. Support should have a checklist of things to review for > Verity K2 installs if you are having issues. With the latest release this > supports Verity K2 and OpenText Common Search. In v11 OT Common Search > integration is deeper, OT Semantic Search is integrated, there is a new > constraint system that should enable more performant searches even in > organizations with large ACLs (users with ~50 group memberships). > > *Cons:* > XML and XSL. I don't see this as a draw back but I know a lot of people > who understand well formedness and validity in XHTML don't want to > translate that to other syntaxes. I think you'll find on Google Group or > Solution Exchange there are people who will help overcome hurdles around > specific issues in implementing a use case. I've trained several > consultants with no prior XML/XSL experience to be Delivery Server > Consultants with little more than some projects and w3schools as a > reference guide so I'd suggest if you have someone who's open and with some > programming or JavaScript knowledge you'll be successful. > > Investment in knowledge. Tony isn't wrong if you don't want to do some > training and/or get some services to get an established environment and > solid foundation you may face challenges down the road and may have been > better using Management Server (with its code agnostic nature) and custom > applications for delivery. If you don't have large libraries of custom code > consider which approach is better suited to your end goals, companies buy > of the shelf applications to reduce costs of custom code maintenance. > > *Summary* > It has real technical benefits. If there are specific challenges you have > reach out to support and your account team to let them know, they may be > able to help and give some advise in that channel as well. The technical > and adoption concerns are that different from those I hear expressed from > time to time around Management Server. A big difference is you don't > execute ASP.Net (JSP, PHP, RoR, etc..) code directly into a Delivery Server > page, you call it via web services, link to it, embed it with portlets, or > serve it content via REST/SOAP. > > -- > You received this message because you are subscribed to the Google Groups > "RedDot CMS Users" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/reddot-cms-users/-/yc1dwZZoLoQJ. > > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/reddot-cms-users?hl=en. > -- You received this message because you are subscribed to the Google Groups "RedDot CMS Users" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/reddot-cms-users?hl=en.
