Hi, first of all you might get more response on the user list rather then dev list to this kind of questions. Second, marking mails to the list as urgent usually doesn't encourage people to answer quickly.
As for your questions see the answers inline. On Apr 7, 2011, at 1:33 AM, Nazakat Ali wrote: > Hi, > Thanks a lot for your guidance and support, I been able to develop a demo > that I am going to present today April 7th 2011 at 9:PM Pakistan time. > > Our US team may ask for the following question, Just for confirmation if > someone can guide me. > > We have following queries: > 1- How much concurrent user supported by magnolia public instance, is there > is any possible limitation? that depends on many factors, mainly on hw and on the amount of processing done to render each page. To name just few: is content cachable, do you make any image operations, do you perform search to retrieve items to display on the page. The advantage of Magnolia in that area is the possibility to scale up horizontally - you can add as many public instances as you need and use load balancer to distribute the traffic between them. > 2- We can develop the spring MVC module that’s really a very power full > feature. Is there is any way we can only move the static contents(pages) with > magnolia and dynamic contents can work the way these working now. In other > words we use CMS for creating static pages and dynamic pages will not are > part of CMS . In this way easily adopt CMS in our application and we don’t > have to alter or revamp the whole web application at this time. But we will > surly revamp the whole application, in this way we can get the more time of > revamping process. by now you might have noticed that on filters in Magnolia filter chain you can setup various bypasses. If you don't want magnolia to handle certain urls just define bypasses for those and they will be passed on to whatever is behind Magnolia filter chain. Alternatively if you have apache in front of Magnolia you can make the decision there and forward only relevant calls to Magnolia. Using the bypasses is IMHO more dynamic and allows you to quickly switch between Magnolia handling the call or anything else. > 3- For creating the template using STK, needs to be modify the STK source > code, in this way we have full control of template. STK default template are > very good but the template that we are using is bit different, although we > been able to modify the STK template without modifying the source code but > still we have not enough control to make our life easy. For Better Template > we have to modify the STK Source code. Is it a proper way to get into the STK > Templating? Although we know we can use the STK without digging into the > source code. As will mentioned there should be no need to redefine the STK code or templates directly since you can reconfigure both template path and model class thus completely customizing any part without need to modify the original. Still the answer is yes, you can modify the code and rebuild it yourself, but it will make upgrade to newer version more difficult. > 4- Our clients gives the option to their customer to create the custom > website using their site. The customer of our clients are actually the > retailers, and retailers develop their site using our client site. Six year > back we have added the option of custom web site in the client application, > where their customer can easily create website by just following a wizard but > now we are thinking to allow them a option to create these custom site using > magnolia. We simple want to create a custom website template and in this way > their customer can easily develop their website. I think it will easily been > possible with magnolia. Is it? is there is any recommendation? Again you have multiple options here to do things as true multisite or via creation of micro sites under the main site. Either way it should be pretty simple to write a wizard that creates new site either by configuration of the original or by extending it and also creates new content structure and sets the right ACLs for it. > 5- Should we use the same database as magnolia is using for our product > management, order management etc or we should use the separate database > schema. What you people will suggest? if you are running multiple installations of Magnolia I'd suggest separate db or at least different schema. This way you have more freedom in making backups, migration or even just regular maintenance. > 6- How user management should be done? Should we use the custom module are we > should use the magnolia security(for the customer of website). That depends on what you need or have already inhouse and want to reuse. I've seen done both, there's no clear winner. > 7- Any other suggestion that might help me to convince the US team. > Especially why magnolia why not other CMS? You should know by now ... was it difficult to create your demo? Magnolia is usually said to be easier to understand then other systems that can handle similar amount of load. It also performs well on the big installations. .... and so on and so on ... maybe read some use case studies on the magnolia-cms.com site to find more arguments. HTH, Jan > > Regards, > Nazakat Ali > Jabs Solution. Islamabad > Cell#: +923009128457 > +923235353709 > > > ---------------------------------------------------------------- > For list details see > http://www.magnolia-cms.com/home/community/mailing-lists.html > To unsubscribe, E-mail to: <[email protected]> > ---------------------------------------------------------------- ---------------------------------------------------------------- For list details see http://www.magnolia-cms.com/home/community/mailing-lists.html To unsubscribe, E-mail to: <[email protected]> ----------------------------------------------------------------
