Is it possible to create a wizard in Orchard CMS, perhaps by creating a "Wizard" content type which may have optional content parts depending on rules which may assess previous data entered. This may be asking too much. I am just looking into Orchard as a CMS and I can see how it can be some much more ie an application framework.
Many thanks,
Ed
Orchard is just an Mvc application so you may use any tecnique that works on it.
Look at this blog to see a step by step tutorial:
http://afana.me/post/create-wizard-in-aspnet-mvc-3.aspx
You may find useful also this article on how integrate mvc in orchard:
http://www.codeproject.com/Articles/434484/Welding-on-Orchard-CMS
Have fun...
Related
I'm quite new in liferay and this must have been a very basic question.
Can we make site templates deployable as standalone component like themes? If yes how can we do this? Any help or content explains how to do this will be great.
Thanks
You can export and import site templates - they'll not be deployed like themes, but you can carry them from one portal to another. Check the cogs-icon in the top-right of the Site Template configuration screen in Control-Panel and you'll find the Export/Import Actions. The individual SiteTemplate's Action button also has an Export option available.
Another option is to get familiar with Liferay's API (learn ServiceBuilder for understanding the concepts) and examine the sourcecode. A good starting point is the ancient 7cogs sample code (not all will compile as-is, this article is for an older version, but the principles will help you to understand). Also note that the article links a second follow-up article. Everything in Liferay is done through the API and you can literally automate everything - you'll "just" have to find the proper API and use it.
Site templates can be deployed in a plugin via the use of Liferay's Resources Importer.
See: https://dev.liferay.com/develop/learning-paths/themes/-/knowledge_base/6-2/importing-resources-for-your-theme for more information.
You can probably find some some examples here: https://www.liferay.com/marketplace/-/mp/category/15828894
First of all, let me tell you what I am or my company is intended to do. We have already developed a project using Java, JSP and Servlet. We want it to integrate with Liferay so that we can change logo, css, images, themes or any other UI related component at run time using Liferay admin panel. But backend should be what we have developed.
In short, the UI of our project is controlled by Liferay, but control of data displayed on UI or submitted from UI should be from our developed backend code.
Now I have a few questions regarding above said approach of fulfilling the requirement:
What we are trying to do is possible?
Is this approach recommendable for what we intended to do?
Or do we need to develop our project from scratch to fit into Liferay? Like developing portlets and deploying in Liferay or other approach that has been given in Liferay documentation.
What about database integration? We have around 15 columns/fields in user table in database of our project which is completely different from that of Liferay's user table.
Liferay is a very new for us. We have checked the documentation section of Liferay but still few things like above said requirements and its implementation is not clear. Also, we would like to know in what scenarios/requirements Liferay is useful.
Ok let me try to answer your question point-wise and I would answer your last question first, which should automatically clear other questions:
Q. Also, we would like to know in what scenarios/requirements Liferay is useful.
This can have a very wide answer, but I have made it shorter for you:
If your site is content heavy and not data heavy then go for Portal
If you plan to use only a single web-application in a portal then I would suggest standalone custom developed web-application is much better.
I agree liferay portal will give you lot of things out-of-box like Single Sign-on, authorization, authentication, friendly-url and page creation and also lot of applications like Blogs, Wikis, Document library, some social networking apps etc. But think about it, do you really need all this? if not, then this is overkill
Here are some really nice links to better understand a portal's usage:
When to use a portal
Why to use portal technology
liferay tag wiki: It has nice description as to what is liferay and it also contains relevant links to Admin guide which will tell you what all functionalities liferay has and how you can manage it.
So still if you find your other questions unanswered, read-on ...
Q1. What we are trying to do is possible?
Nope. Portlet technology is different from Servlet technology. Liferay (or anyother portal) does not provide a way (atleast a simple one) to integrate servlets that would render pages inside a portal. For eg: Since with servlet you define URL mappings for a particular servlets before-hand in a web.xml but in a portal the URLs are generated by the Portlet Container. So portals work with portlets and not Servlets.
Q2. Is this approach recommendable for what we intended to do?
Nope. As I already explained in Q1.
Q3. Or do we need to develop our project from scratch to fit into Liferay? Like developing portlets and deploying in Liferay or other approach that has been given in Liferay documentation.
If you want to go the liferay way then Yes.
If you want to build applications that talk to your custom tables then portlets are the way to go.
Q4. What about database integration? We have around 15 columns/fields in user table in database of our project which is completely different from that of Liferay's user table.
If you go with Liferay. In this scenario you can create a combination of liferay-hook & portlet (may be using service-builder) to customize liferay's User creation mechanism and there by store data in both Liferay's User table and your custom tables.
Liferay's permission system is really fine-grained so you can also benefit from this system and put permission even on the data level.
In conclusion I would say:
Everything boils down to what your requirements are and what resources you have. And sometimes what future requirements you can have.
Note: All the terms used in this answer which are specific to liferay (like service-builder, hook etc) are explained in the liferay tag wiki.
Hope this helps. If you would like to know anything specific I would gladly update my answer.
I'm not sure that there will be a definitive answer to my question, but I'd like to read some discussion from other folks on this... here's some quick background.
I'm creating a request form that will handle adding new equipment to our datacenter. I'm collecting some pretty basic info about the submitter and the equipment to add. Some of the metadata gets pretty complex, but I won't get into that here.
At first I started with a browser enabled InfoPath form, because most of our users aren't licensed for the InfoPath rich client. After much frustration I got things working, but could never get a level of performance that I was happy with. Since then I have been playing around with SharePoint's web services and I have a GREAT form that I've written in HTML (with some jQuery magic) that submits to a SharePoint list.
So now I'm asking myself... why not just use this form? First, I can get rid of InfoPath completely... that also helps us out with licensing since I won't need Enterprise licensing. Second, performance... Third, sure I have to hand code it, but I can, and I enjoy it.
So, InfoPath is out the door.
That leads to where I need some best practice ideas mixed in with new ideas. I've got this form that works great, but I want everything to work within SharePoint. As a test, I just created a new view for my list, removed the web part that shows the list, and plopped in my form. Aside from some CSS issues, everything works and it updates the list lightning quick!
But should it be a custom view? Should it live somewhere else? Should I just edit NewForm.aspx?
I'd love to hear some thoughts on this. Ultimately, my entire solution will be deployed as a Feature, but I'm not sure that's relevant.
Thanks!!
I would've done it mostly the same way:
Create a new form (via SharePoint Designer or a custom ASPX page)
Encapsulate the form in a Web Part (you can use the SmartPart Web Part if you're in a hurry)
Create as many custom views as you want, it doesn't really interfere with the way you code the form
If you must modify NewForm.aspx, don't delete the default ListForm Webpart since it's used by SharePoint for other things. You're better of just hiding it to avoid future issues.
Hope that helps
I think you should create custom form templates for your request SharePoint-List.
See MSDN: Creating Custom Form Templates.
I also recommend reading Understanding SharePoint: List Forms.
There's nothing wrong with using a custom form or a completely seperate app to edit SharePoint data. You end up with the same data you would get from using the standard new form, so it can't possibly break anything beyond the modified view.
Setting up a custom newform is probably the most appropriate place for it - easy enough to change the newform url in schema.xml or through designer.
I have a task that I need to perform for a friend as a favor, to modify some forms on a MOSS/Sharepoint site to add some javascript to each form for some SEO tracking purposes.
I've had a little bit of exposure to Sharepoint, but it is mostly by using the Sharepoint Designer 2007 tool.
I am able to navigate to the site, and I can see the content in Sharepoint Designer. However, I am not able to see the forms, and I'm a bit stuck.
Here is an example of a form that I need to modify:
http://www.MY_SITE_GOES_HERE.com/forms/covg_order.aspx
I've read a little online, but I'm stuck. I don't know if these are infopath forms or what. I just need to modify the forms.
Is there a simple answer to this problem? Or a good resource to get up to speed quickly for this task?
I'm not a sharepoint expert, so thank you in advance for answering a simple question.
While hardly the simplest approach, but since this is a developer site, I would recommend creating a DelegateControl to add to your site. Using DelegateControls has several benefits, for example:
the ability to selectively activate and deactivate the controls through features
no need to modify any out-of-the-box files which would break supportability
ability to output different content on a page-by-page basis
You can opt to use one of the DelegateControls of the default master pages if you need to deploy to an existing site based on one of the default site definitions. The AdditionalPageHead is a favorite among developers, as it allows multiple overrides to be active at the same time.
If you want to create your own master pages you can add DelegateControls as you like.
If you want to learn more about DelegateControls you can check out the first issue of Understanding SharePoint Journal (Disclaimer: I wrote that issue). Also, check out the MSDN article on How to customize a Delegate Control.
.b
you can also check PowerForms which is a silverlight webpart that fully customizes sharepoint forms. You can add business logic in forms using custom assemblies and a lot other advanced tasks. Give it a try, i think it will solve a lot of problems.
http://www.bpc.gr/powerforms
You have a couple of options here:
If you need to add a unique code, like Google analytics you should probably deploy your code to the master page.
In case you need to customize forms for lists you will have to do it with SharePoint designer. In that case you will find EditItem.aspx and NewItem.aspx with SharePoint Designer pages or any other custom page. Open SPD, locate your list, expand it, look for Forms subfolder and you will find all the forms there.
Microsoft Office SharePoint Designer is now free, as of 1-Apr-2009. It's a good tool, not only for modifying individual pages, but for entire sites.
Are there any blogs, guides, checklists, or controls we should be using to ensure our SharePoint implementation is accessible?
Preferrably to the W3C double A standard, or as close to that as we can get.
We're implementing an extranet solution.
This study has already been funded by Microsoft, and unfortunately the results only seem to be online in a Word Document.
The document is hosted on this blog:
http://blog.mastykarz.nl/best-practices-for-developing-accessible-web-sites-in-microsoft-office-sharepoint-server-2007/
And the path to the document is here:
http://go.microsoft.com/fwlink/?LinkId=121877
I'm unsure on whether it would be a good thing to copy the contents of that into here to fully answer the question in a way that will be indexed by search engines, but I'll play safe as it's not my content.
The best place to start is the Accessibility Kit for Sharepoint. With this, you may reach single A standard, but in my experience, you will find it very tough to reach AA.
Microsoft didn't factor in accessibility in Sharepoint, and even 2007 suffers from a huge overdependence on table layout.
Good luck!
How are you deploying the implementation? Is it as an Intranet, or, is it as a public facing website.
I think one of the first rules is to be extremely selective with the use of out of the box web parts. Many of the web-parts I looked at weren't compliant even on a basic level.
Andrew
The best way is to run checks as you develop so you know where your pain points are.
The next step maybe to start with a minimal masterpage so you can choose what elements are presented to the user.
More advanced you can override the render methods to remove or change bits of the page that are not compliant with your checks. EG changing the case of tags (XHTML does not like all caps)
A bit more in this guide.
http://techtalkpt.wordpress.com/2008/06/18/building-accessible-sharepoint-sites-part-1/
http://techtalkpt.wordpress.com/2008/08/07/building-accessible-sharepoint-sites-part-2/
I recently read the MOSS book by Andrew Connell (www.andrewconnell.com) and it has a chapter dedicated to accessibility and SharePoint sites.
Simply put SharePoint sites are very difficult to generate W3C AAA standards, but the Accessibility Kit is one of the best starting points.
Stronly recommend his book for this chapter (http://www.amazon.com/dp/0470224754?tag=andrewconnell-20&camp=14573&creative=327641&linkCode=as1&creativeASIN=0470224754&adid=18S6FKQJR5FZK56WHH6A&)
It depends how much of Sharepoint out of the box you are intending to use. In implementing our public facing site we managed to achieve AA compliance, although the amount of custom development required has raised questions over the benefits we are actually gaining from using Sharepoint in the first place.
A few pointers:
We made heavy use of SPQuery/SPSiteDataQuery to render site data to screen using xslt which gave us full control over the output. I found this link helpful:
http://blog.thekid.me.uk/archive/2007/02/25/xml-results-using-spsitedataquery-in-sharepoint.aspx
Check out RadEditor for Sharepoint for a nice accessible rich text editor for publishing.
For xhtml compliance, things were a little more tricky, we had to override most of the Sharepoint publishing controls' render methods to correct dodgy output.
If you are wanting to leverage the portal like capabilites of Sharepoint in your extranet it is more problematic. The web part framework is not accessible and I have not yet found a way to make it so. Any suggestions welcome!