When using the Orchard UI to create queries, how do we eager fetch fields? For instance, we have a content type that has an input field, link field, media library picker field, date time field, and text field. None of these fields are terribly complex. How do we eager load fields from the UI? I've looked at the Eager Load filter, and based on intuition, have considered eager loading the FieldIndexPartRecord.
You don't need to: fields are stored in the Infoset, which is a XML data blob stored on the content item's record. Therefore, it is always eager-fetched. Do you have profile data indicating otherwise?
Related
I filtered out XPages view with 'search' option. Then I'd like to access all of the documents by SSJS.
If I access the bound Notes view by database.getView("ViewName"), the view is not searched and could not get the searched result.
How can I access the document collection?
The dominoView data source is just a wrapper that runs calls on the underlying view to return a subset of entries to display in a view component (Data Table, View Panel, Repeat, Data View etc). Consequently, unless the rows property is set to a large enough value to get a handle on all responses, you’re unlikely to be able to access what you want that way.
The best approach will be to run the search on the backend view in SSJS / Java.
See https://www.intec.co.uk/understanding-xpages-views/ for a more detailed explanation of the different elements involved and their inter-relationships.
I'm looking to query the Content Store database to get a list of all fields in a specific framework model. I also require the source (Database.TableName.Field) of each field and also any calculation / transformation.
Is this possible?
I want a metadata field getting values from database record. This metadata field should be added to document.
Can anyone provide a solution to my requirement.??
I presume you are using Liferay 6.1.
Web Content Structures
As for Web Content, you could programmatically create a JournalStructure (see JournalStuctureLocalServiceUtil) and populate the list of possible values for your structure field with values coming out of the database. You can put this "import code" inside a batch job, so your structure field and the values inside the external database are always in sync.
Document Metadata
How to do this with Metadata Sets is probably more interesting, as not only Dynamic Data Lists and Documents & Media use this in Liferay 6.1; as of 6.2, Web Content structures will utilize the same metadata API in favor of the old Journal API.
For this to implement, check out the xsd column of the DDMStructure table. It has more or less the same format as the XML for a JournalStructure, however there are more options available. Use DDMStructureLocalServiceUtil#addStructure to add such a new structure. Again, run this inside a batch so you always have the latest external DB values.
I'm trying to dynamically construct URLs in an ASP.NET MVC website that point back to a SharePoint list view with a Key Filter enabled for a managed metadata field (which uses a TermSet).
If I configure a navigation hierarchy for the managed metadata field, I see the following in the URL:
TreeField=MyCategory&TreeValue=0C37852B-34D0-418E-91C6-2AC25AF4BE5B
However, if configure the managed metdata field as a KeyFilter, I see the following in the URL:
#ServerFilter=FilterField1=MyCategory-FilterValue1=247-FilterLookupId1=1-FilterOp1=In
Where does the FilterValue1 value of 247 come from? It is not the database id of the MyCategory term. It is also not present anywhere on the Term object when loading the taxonomy through the SharePoint API. Is there a way to construct the query string to use the guid for the term (or better yet, the label, which I know will be unique).
The value comes from the taxonomy hidden list. Use the following method GetWssIdSoftTerm to get the int value the above urls are using to filter the data.
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.taxonomy.taxonomyfield.getwssidsofterm.aspx
I am designing an application that will display dynamically-generated forms to the user who will then enter values into the form fields and submit those values for persistence. The form represents an employee evaluation.
One use case allows an administrator (from HR) to define the form fields. They should be able to create a new form, add/remove fields from a form and mark a form as 'deleted'.
The second use case is when a manager views the form and enters values into the form fields for a specific employee. They should be able to save the values at any time and recall the saved values when viewing the form again for the same employee.
Finally, when the manager is satisfied with the values they've entered for that employee, they can 'submit' the form data which persists the flattened data into the data warehouse for reporting purposes. When this is done, the 'working' copy of the data is removed so the form will display empty the next time they view it for that employee.
I am not concerned with the front-end at this point and working on the back-end service application that sits between the client and the data store. The application must provide a course-grained interface for all of the behavior required.
My question is how many aggregate roots do I actually have (and from that, how many repositories, etc)? Do I separate the form definition from the form data even though I need both when displaying the form to the user?
I see two main entities, 'EmployeeEvaluationSchema' and 'EmployeeEvaluation'. The 'EmployeeEvaluationSchema' entity would have a collection of 'FieldDefinition' value objects which would contain the properties that define a field, the most basic being the name of the field. The 'EmployeeEvaluation' entity would have a collection of 'FieldValue' value objects which contain the values for each field from the definition. In the simplest case, it would have a field name and value property. Next, the 'EmployeeEvaluation' could have a reference to 'EmployeeEvaluationSchema' to specify which definition the particular evaluation is based on. This can also be used to enforce the form definition in each evaluation. You would have two repositories - one for each entity. If you were to use an ORM such as NHibernate, then when you retrieve a 'EmployeeEvaluation' entity, the associated 'EmployeeEvaluationSchema' would also be retrieved even though there is a dedicated repository for it.
From your description it sounds like your objects don't have any behavior and are simple DTOs. If that is the case maybe you should not bother doing DDD. Can you imagine your entities without having getters? There are better ways to do CRUDish application than DDD. Again this is only valid if your "domain" does not have relevant behavior.