HI All, Just to be clear, my previous comments are my own opinions only and am I not speaking on behalf of Open Text.
To Dan's points, LiveServer is very good at working with XML content, and it was great for manipulating RSS feeds, etc. If you are a superstar with XSLT then you'll have a lot of fun in LiveServer. I'm glad to hear that there is tighter integration starting between CMS templates and LiveServer logic, as this piece was missing earlier on. Something I realized after working with LiveServer for a while is that it bears a strong resemblance to ColdFusion, and many of the same pros/ cons exist between these two platforms. This type of platform isn't right for everyone, but it does have benefits in certain organizations. As for web components, they had just came out as I was leaving the company, so I didn't have much experience with them, and I haven't followed their development since then. Best, - Eric On Jun 10, 6:39 am, Danny Baggs <[email protected]> wrote: > Hi all, > > To introduce myself, I am a Solutions Architect at Open Text and joined 4 > years ago when the company was RedDot. > > I would say that there is a fair amount constructive critique in this > thread, which I tend to agree with to some extent as I spent significant > time within the professional services teams within the UK and then Germany > and so I have been close to a number of project implementations over a few > years. More recently, I've worked with the RedDot product set on internal > projects. > > Therefore, I think it is important to point out some things that example > where we as an organisation are listening to this critique and are applying > changes to acknowledge where they're needed. > > When I worked in professional services, I always positioned the strengths of > LiveServer (now Delivery Server) as being a product that is strong in simple > personalisation and intregration. This meant that it has played a key role > in many websites in combination with other offerings. For example, I have > always deployed the product sitting behind a front controller web server > such as Microsoft's IIS and Apache's HTTP Server, allowing for best-practice > delivery of static content such as images, javascript, and css alongside the > dynamic delivery from Delivery Server as such widely adopted web servers > have built in ways that static content delivery can be optimised e.g. > setting Expires HTTP headers to optimise browser caching. If you wanted to > find out more on this subject, I wrote a blog article on this > here:http://bit.ly/ad3oai. > > Delivery Server is by design built to work very well with XML based > technologies and uses open and easy to use standards like XSLT to allow for > delivering the right content. Although the XSLT is used specifically in > Delivery Server, I've always advised to keep it as content classes within > the Management Server for the benefit of being able to allow business users > to influence the underlying parameters through standard Management Server > placeholders and not being exposed to the technical language underneath. > > I would however agree with the sentiment here that the XML based DynaMent > language (the programmatic server side scripting language) has a learning > curve associated and can appreciate the challenge with that. However, on > the positive side, it does encapsulate behaviour/feature well into blocks > of embeddable XML. Given this, we acknowledge this and are now focusing > more and more on how such programmatic logic can be abstracted further into > standard Management Server templates with standard placeholders influencing > the various parameters. This means that we are moving to a model where > business users are empowered to influence behaviour on their sites in much > the same way as the Management Server has empowered the same business users > to own and manage the content. This is being facilitated by additional > Management Server features such as the drag and drop of content classes into > container elements within SmartEdit and only the relevant parameters being > exposed via placeholders providing that business user control. For example, > I have used the Web Services connector to good effect in this way when > integrating with the Salesforce Web Service API allowing the input of a > given Campaign ID parameter to be the only thing permeated up to the > Business/SmartEdit user through standard templating. > > This supply of pre-made Management Server templates encapsulating DynaMent > logic is something we are very keen to grow and certainly would like to > encourage contributions from the broader community. To that end, we've been > working on a platform that helps the broader community and this can be seen > athttp://beta.solutionexchange.info. This is by no means the finished > thing as this is still on non-optimal hardware but we are keen to already > listen to you in the community and work with you to provide things of value > and to also provide a constructive collaborative voice for the things that > you would like to see in the products. > > Whilst talking about the community, it is worth mentioning a few words > around 'Web Components'. Through the aquisition of Vignette last summer, > Open Text has inherited a mature product, which has strengths in its social > features. The product now to be called Open Text Social Communities exposes > a REST based XML API through which blog, wiki, forum, tagging, review, > rating, and commenting functionality can be obtained to name but a few > things. As alluded to earlier, Delivery Server works very well with XML > technologies and this is exactly the approach I've taken when building out > the community to its current (incomplete) form with many of these features > being planned for the future as we iterate and evolve the platform. I've > again chosen to implement the approach mentioned above where by the > commenting, rating, and tagging type functionality is encapsulated within > Management Server templates. > > To take one final example from this context, the twitter feed (using > Twitter's REST based XML API) is encapsulated in much the same way, with the > caching time (a technical parameter for how often the twitter feed should > refresh) being exposed as the following question in SmartEdit for that area: > "After how many minutes, should the community tweets be refreshed?". Again, > abstracting in this way allows us to once again focus on serving the > business user, which is something I accept we may have lost a little sight > on previously but are keen to correct. > > I would always welcome further discussions and feedback to help improve our > products so grab me at the user group in the UK on June 30th or head over > tohttp://beta.solutionexchange.infoand register to help your voice be heard > within the right audience and help us evolve something that meets your > needs. I tend to pick up the phone to all who register to talk through > where we are at with the community at this point in time and what we're > after in beta testers/users. > > Kind regards, > > Dan > > On 9 June 2010 22:28, Christian Burne <[email protected]> wrote: > > > > > I do not know of any, but then again, I only know of our customers. I > > haven’t asked OT for this information, but I wouldn’t be surprised if they > > couldn’t come up with any that have implemented it either. It was fairly > > half baked since they released it. > > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Henry Lu > > a.k.a. Javahand > > *Sent:* Wednesday, June 09, 2010 11:34 AM > > *To:* Christian Burne > > > *Subject:* [reddot] what does liveserver actually do > > > Do you happen to know ONE example of WebComponent implementation on a > > active public site? > > > And I am glad you said they were useless. > > > Henry > > > On Wed, Jun 9, 2010 at 2:00 PM, Christian Burne <[email protected]> wrote: > > > A couple things from my perspective. We (www.oshyn.com) have been > > implementing sites w/ OTWS MS and LiveServer/Delivery Server for about 3-4 > > years and have found it to be a decent platform. It's a java app so it > > requires love and tuning to make it work well, but that's the same with any > > java app. If you want to do content personalization and/or secuirty of > > content from OT CMS, it works well enough. > > > What we tell our customers is: If you need to do custom functionality on > > your external site, you need SOME platform to do it. If you have existing > > .NET/PHP/Java components or people that you want to use, it's fine to > > publish from OTWS MS into those apps. If you have nothing and you need > > something, DS will do just fine. If you have personalization and content > > security requirements on OTWS MS content, that also pushes you back to using > > Delivery Server and taking advantage of pre-existing components using the > > connectors (typically web services work fine). It typically is more work to > > build content security and content personalization of OTWS MS content in > > PHP/.NET/Java than it is to just use DS. It's really a question of where > > the balance of your requirements lie in order to determine the right > > decision for you. > > > I also agree with some other posts that Verity search results can be > > somewhat disappointing and at the very least, tuning serach results are more > > manageable from GSA or google mini and will yeild better site search results > > overall than verity. However many times, we've implemented BOTH: used > > GSA for site search, but used Verity for personalization and security. > > There are also some other performance advantages to using this combined type > > of architecture, but it's more stuff to maintain. > > > Dynamenst aren't really that hard to learn and they are tuned > > specifically for OT content and personalization of that content. The > > problem is, it IS another language one must learn (and it doesn't really > > help anyone on their resume). I don't really know why they chose this > > instead of using something standard. They do have basic programming > > constructs like: if/else, looping, setting/retrieving variables, calling > > external database or web services. These are the basics you tend to need > > when building a content driven website. If you need to do anything that > > can't be done in Dynaments, you can easily drop down to Java and do whatever > > you need to do there. > > > Web Components is fairly useless as an architecture, however, the > > components that they've created are super basic and can/do work. I've > > talked about implementing them a number of times w/ clients but never have > > b/c of the feature requirements. We have them in our lab environment so we > > know they work. If you need anything sophisticated out of > > Forums/Blogs/Calendars/Comments, etc., then you won't find them in those > > components. HOWEVER, if you need the content in them personalized or > > secure, it's much easier to do by using the Web Components instead of > > integrating a 3rd party system. Also, i've got a number of customers who > > don't have immediate needs and are therefore waiting to see what crossover > > will come > > ... > > read more » -- 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.
