I'm very new to Orchard (and ASP.NET MVC) and I'm having some difficulty wrapping my head around how Orchard part properties can be automatically set in a controller. I have a "Gallery" content type, consisting of the stock Title, Container and Owner parts. I'm creating a controller with a Create method that hides all of the details of the Container part since I'm going to set the default page length, the item type, et cetera in the HttpPost version of the Create method. My problem is I don't know how to set those values on the http Post.
My general plan was as follows:
I created a CreateGalleryViewModel containing the title and admin username, both as a string. IN the view those two are represented as form fields. On the submit, I could run TryUpdateModel in the controller to update the CreateGalleryViewModel with the form values. But then how do I update the Part properties? I think I'm supposed to run IContentManager.UpdateEditor(, this) but I don't think this ca, work because I never ran IContentManager.BuildEditor in the first place. Here's where I'm stuck because I don't see how the content parts get validated and updated properly.
Am I looking at this at the wrong level of abstraction? How do I make a simplified editor for my Gallery content type?
What you basically need to know here is the following:
You can build the editor of a content item with IContentManager.BuildEditor()
You can updated an item's parts' values from the POST data with IContentManager.UpdateEditor()
You can also access parts by "casting" content items with the As() method (needs the Orchard.ContentManagement namespace).
When you're dealing with content items because of their dynamic nature it's rarely a good approach to create a view model where you recreate some of the parts' properties. If you have such static view models for what's contained in a content item then you'll miss the extensibility and flexibility that comes with Orchard's content model. E.g. if you add a new part to that content type since you're using a static view model the new part won't be handled.
For a complete example of how to manage content items from code, see the Training Demo module.
Related
I have created a new ContentPart with a ContentPartRecord in a custom module and attached it to an existing content type on my website that already has hundreds of content items.
Now when I perform queries of the format contentManager.Query<MyPart, MyPartRecord>().List() I don't get any results since no MyPartRecords actually exist in the database yet.
Is there a way to make sure this happens for all content as soon as my part gets attached to a content type, or will I have to manually interact with all of the items before they become queryable?
This query is asking for all content items that have that part, which is not the case of items created before you added the part to the type definition. See the type definition as a blueprint more than a schema. Depending on what exactly you're trying to do, you may want to try to query by content type instead.
The part will get attached next time the item gets updated, pretty much. You could build something that scripts the operation on existing items, but nothing out of the box will do that.
I need to create a portlet in order to change the default category behaviour/interface in Liferay 7.
My objective is to duplicate assetcategory table, expand and change its columns, and use this new table as a reference for categories within Liferay backend.
Therefore there are three key points my portlet has to update:
The category organization UI to create/update category tables on
DB. I’m able to create a new Liferay module project (panel-app template) which can present the UI backend interface from the side menu and interact with the DB.
Override default category selection panel within web content
properties panel (metadata > category select). I can create a new
Liferay module project fragment to override the
com.liferay.asset.categories.selector.web, however I’ve noticed I can
select only one file path (eg. META-INF/resources/view.jsp)
Override default asset publisher filter behaviour in order to allow
my custom categories selection. I’ve not yet investigated this
point.
I’m currently stuck at point 2 because after creating a new Liferay module project fragment, set the target Host OSGI Bundle to com.liferay.asset.categories.selector.web (which I believe is the correct one, please correct me if it isn't) and selecting the overridden files as META-INF/resources/view.jsp, I can’t proceed to redraw the category selection interface.
Here my attempts:
Updating the code view.jsp (eg. adding some text string) I can correctly
see them in the portlet.
Removing/commenting all the code in view.jsp an error is shown:
Asset category selector is temporarily unavailable
Selecting all three files available to be overridden in the main
portlet wizard (META-INF/resources/view.jsp, init.jsp and
init-ext.jsp) and updating view.jsp (like the first example) nothing
happen in the portlet
Some screenshot below:
Case 1
Case 2
Case 3
I need to create a portlet in order to change the default category
behaviour/interface in Liferay 7. My objective is to duplicate
assetcategory table, expand and change its columns, and use this new
table as a reference for categories within Liferay backend.
Just this alone sounds like a humongous task, bigger than what would fit into a stackoverflow question.
AssetCategories are used in every single content type, e.g. WebContent, Blog Articles, Message Board Posts, Wiki Pages, Knowledgebase Articles etc.. Replacing such a vital component by your own implementation is something that will safely ruin your next upgrade experience, because there you'd have to do this again, bringing your code to whatever changes will be made in the next version. And this "upgrade" includes Security Patches.
Overall, your premise sounds to me like a x-y problem and I'd rather recommend that you step back from your intended solution and look for other options to meet your business requirements. There surely are some.
My recommendation: Rather add something to the platform than ripping out a very central and generic component, reimplementing it in a business-specific manner. If you need a different filtering than Asset Publisher provides: Build your own Asset Publisher and implement the business specific rules there. Or think again about organizing your content in a different way than you currently organize it.
Unless you're already a Liferay Core Developer and are asking for a hint on how to change the implementation for the next version. But your question history here doesn't look like it.
I am building a liferay theme, which has two columns side by side. The right column is where the web contents will be displayed.
My implementation aims to build a menu (left column) that gets the titles from the web content titles and builds hierarchy (parent, child) based on a 'select' structure field that I added to each web content.
So far I was able to build this system using
Liferay.Service('/journalarticle/get-articles'...)
and some javascript coding.
Now the 'select' fields i use in my structure have predefined hard coded options.
How can i populate dynamically this option list so that whoever is managing content will automatically have all titles from all web contents available to choose a 'parent' from? So far a developer has to update this option list each time there is a new web content added.
#chadct : AFAIK Liferay not provide this default functionality, this is not good practice to populate dynamically value in structure field. But you wanted to achieve that functionality, then there are 4 solution :
Add one text field in structure which contains articleId of your parent web content.
You can add related article for that web content and write some sort of code to get article which consider as a parent of that web content.
Create Select DOM options form template which hold the list of article according to groupId and render on web content view mode, then you can select parent content from there and update content expando with articleId of parent webcontent. Remember this contains AJAX post request. and only show that control who is admin or loggedin user or depends on Role. Refer AJAX post calling
Hook edit_structure.jsp and add your logic here as you want.
Note : last one is worst but also a solution, Remember you need to modify your current solution.
I am using Microsoft coded-ui testing (CUIT) in VS 2010 Ultimate to test an ASP.Net 4.0 site.
I have the source code to the ASP.Net site, so I can modify it as needed.
I've got record/playback working.
I can write simple assert statements in the test methods to check properties of the UITestControl descendents (HTML links, tables, etc.) and compare them to expected values.
I want to add properties to user controls (ASCX's) and pages in my site, to pass back useful values to the testing code.
For example, I have a user control that implements a menu which displays different sets of menu items depending on the role of the current user.
Rather than having the test script click at the various menu items to check whether or not they're present, I want to add a property to the user control. This property will return info to the caller, listing the menus and menu items present.
I've found info on the Net on how to do this in WinForms, but this code relies on accessability, which I believe is only useful for CUIT with WinForms. Likewise, I've found info on how to do it with WPF/SL.
The answer may be related to getting the UITestControl.NativeElement property, then calling a method that overrides GetProperty(), but I haven't been able to get this approach to work.
Can anyone provide a short code sample showing how to add a property to an ASCX or ASPX page, where that property can be written in C# code-behind, and read by Microsoft Coded UI Testing (CUIT) code?
Thanks!
Adam Leffert
http://www.leffert.com
I haven't found an answer to this question, but I have written some code to solve the underlying problem.
I realized that adding properties to user controls would keep the validation data together with the control under test, but only for the case where the section of UI was implemented as a user control.
There are at least two other cases I need to cover:
1) Third-party controls added to the page, for example ASPxGridView, ASPxTreeView, etc.
2) Items that are not visible in the UI, for example the user profile data for the current user.
When you're running CUIT validation code with a Web app, the data you have available is DOM data, i.e. a tree that represents the contents of the Document Object Model of the contents of the browser window. There is no Request object, .Net Page object, etc. This DOM data is accessible through the UIMap object.
I don't want to wrap the third-party controls in user controls, because doing so would disturb the application under test, causing me to re-write the application code that touches properties and events of the grid, tree view, etc. Too intrusive for testing code.
So I created a code interface (ITestable) that contains a dictionary of string values, and a list of ITestable children.
In the LoadComplete event handler of the master page, I create an ITestable for the master page and fill the list with child ITestable objects for the child page, which can themselves contain lists of children.
I serialize this object into JSON, then store it in a hidden field on the master page.
I added the hidden field to the UIMap.
The test validation code deserializes the ITestable, then looks through it for values that need validation.
The controls create their own ITestable objects, so they can easily fill the objects with values that may be needed for validation, rather than forcing the test code to manipulate the UI trying to read validation values.
For example, a tree view could return its contents without the testing code having to click on each node and try to read the value displayed there. Additional properties (visible, enabled, etc.) can be stored in the values dictionary for each ITestable object.
CUIT has some very powerful features. I would very much appreciate it if Microsoft would document some best practices for solving these non-trivial validation problems. I've read through the Microsoft documentation but haven't found much on this topic for Web apps.
I've got a custom list with a custom content type. I'm aware that when you create a new item you can see a drop down for the different content types on that list which I assume all have their own NewForm.aspx somewhere. I can specify in the content type definition which columns are shown on the New form and that I can replace the new form with a custom one of my own design.
What I'm trying to achieve is to have multiple New forms but for the same content type listed on the New drop down. I would like each new form to expose different fields of the content type. Additionally I'd like to make particular New forms only visable by users with particular permissions although this isn't critical.
Scenario:
I've got a content type with all the fields I need for a risk assessment. When a new item is created it only exposes fields to enter contact details. Once this is created a workflow with infopath forms then drives the gathering of the rest of the risk assessment information through booking, the inspection itself and approval of the data. I want the ability to have a second option to easily enter all this information on a different new form for an inspection that's already been done and needs logging in the system.
You could customize the NewForm.aspx (e.g. via SharePoint Designer) for the initial submission case. Obviously, all of the required fields will need to be populated in some fashion.
The EditForm.aspx is the out-of-box page for updating existing list items. You may be able to customize this to meet your update an existing risk assessment case. From the post above it's not entirely clear to me whether this distinction between these pages is fully understood.
In both of these cases, you can add code-behind to the .aspx pages. However, it's usually best to start as simply as possible, keep it as simple as possible and only add complexity as necessary.
Hope this makes sense and helps. Good luck!
Dan,
Per your scenario, I have done something similar by creating one content type per actor/stage. Consider using a simple SharePoint Designer workflow to change your content types onChanged (simply by setting the Content Type) column so that the perspective actors only see the columns you want them to see in the edit/newforms. As long as the proper content type is set, your users will only see the fields you want them to see. Furthermore, with creative use of views and audience targetting of pages you can somewhat prevent these users from seeing columns.
Also, you can prevent users from seeing the different content types (under the new button) in the advanced content type page.