I need to access to the Main Page information from any of the Secondary Pages (1,2,3,4...) using a page relationship, and then retrieve the relationship list from the main page, in this case SecondaryPage1,SecondaryPage2,SecondaryPage3, etc..
I have the following structure
MainPage (Page Type e.g. Article) isRelatedTo:
SecondaryPage1 (Page Type: e.g. Item)
SecondaryPage2 (Page Type: e.g. Item)
SecondaryPage3 (Page Type: e.g. Item)
SecondaryPage4 (Page Type: e.g. Item)
SecondaryPage5 (Page Type: e.g. Item)
Is there an easy way to do it? I am using a CMSRepeater to display the items. I am thinking on creating a custom CMSRepeater for this specific scenario but I would like to know if there is a different approach.
So, to recap, The SecondaryPage1 isRelatedTo MainPage on the right side.
MainPage -> isRelatedTo -> SecondaryPage1
I am trying the display whole list from the MainPage, I need to access to that information on any of the secondary pages.
I created this code, it works pretty well I am just trying to discover is there is simpler solution or if there is an alternative.
....
List<CMS.DocumentEngine.TreeNode> mainRelatedItems = new List<CMS.DocumentEngine.TreeNode>();
mainRelatedItems.AddRange(DocumentHelper.GetDocuments().Types(PageTypes.Split(';')).InRelationWith(CurrentDocument.NodeGUID, PageRelationship, relationshipSide));
List<CMS.DocumentEngine.TreeNode> secondaryRelatedItems = new List<CMS.DocumentEngine.TreeNode>();
foreach (CMS.DocumentEngine.TreeNode item in mainRelatedItems)
{
if(ExcludeCurrentDocument)
secondaryRelatedItems.AddRange(DocumentHelper.GetDocuments().Types(PageTypes.Split(';')).InRelationWith(item.NodeGUID, SecondLevelPageRelationship, secondaryRelationshipSide).Where(x => x.NodeGUID != CurrentDocument.NodeGUID));
else
secondaryRelatedItems.AddRange(DocumentHelper.GetDocuments().Types(PageTypes.Split(';')).InRelationWith(item.NodeGUID, SecondLevelPageRelationship, secondaryRelationshipSide));
}
....
CustomRepeater.ItemTemplate = TransformationHelper.LoadTransformation(CustomRepeater, TransformationName);
CustomRepeater.DataSource = secondaryRelatedItems;
CustomRepeater.DataBind();
....
In your document query, you can specify the relationship GUID as well as the side and relationship name. It doesn't have to be the current document.
DocumentHelper.GetDocuments().InRelationWith(guid, "reltionshipname", side)
** UPDATE **
Based on the most recent update of your question, you'd need to get the Main document id/guid by URL parameter or session or some other parameter, then look that node up using something like DocumentHelper.GetDocument(MainDocID). After you have that Main document, you can perform your lookup using the code I provided above.
It doesn't sound like you have a great way to get this info simply because one of those Secondary pages could be related to possibly many other pages or page types. One suggestion may be to create a very specific relationship name and simply query your Main document by that very specific relationship name and the Secondary page ID to get any Main pages that may be related to it.
In my application, i would like to replace a viewpanel with a repeat control.
However, part of the functionality is there is a UI aspect that allows users to select certain fields (that correspond to the view), and only display the documents that match. The view is doing a filter that allows users to select aspects of the view to create a search (the code is under search of the view) that allows the view panel to be updated with the results of the search.
one of the things that is curious is that the viewpanel has a value of "#{javascript:view2}" vice an actual view name.
The viewpanel defines the search view and the ...
I'd like to be able to apply that same functionality to the repeat control. I don't see those attributes on the repeat control... Any pointers? Its been a while since i've worked with xpages... long enough that I've forgotten a lot already....
TIA !
Read this blog post I did a while back, it should explain what you need.
The view panel doesn't filter anything, it just displays rows from a datasource, same as a repeat control. Indeed you can add components to a ViewPanel's column, pulling from the current row by adding a var property to the dominoView datasource.
The view is bound to #{javascript:view2} (which would be better done by binding to #{view2} - there's no need to call SSJS here). view2 is a dominoView datasource somewhere on your page. The datasource is a wrapper that has properties to capture the settings for filtering and searching that you want to do. At runtime, they are calculated and changes the ViewEntries in the datasource.
Finally there's is the underlying Domino View object available also to LotusScript. This holds and will always hold all entries. The dominoView datasource queries that using the filtering and searching properties and retrieves a ViewEntryCollection or a ViewNavigator.
So whether you use a View Panel, Repeat Control, Data View or whatever else, those are just components to visually represent a collection of ViewEntries or Documents. All can be bound to a dominoView datasource. Where repeat controls and Data Views give you extra power is you can bind them to any kind of collection, not just a dominoView datasource (e.g. DocumentCollection, ViewEntryCollection, multi-value field, Java collection, etc).
I often find that doing the searches in Java and then passing the results to the repeat as a List work better and allow more options. I can get all the information I need in Java and load that into a Map or Tree. This gives me the ability to do custom sorting in the Java class and also to combine data from other views/databases easily. Since the data is now in memory it gets reloaded fast. The only thing you have to watch for is the size of the data. If you have a view with many entries (10K?) you might not want to load everything into memory...
Howard
I'm not sure if you've found a solution yet, but consider using jQuery dataTables. Oliver Busse wrote a very detailed blog post about integrating dataTables into XPages.
To get the specific formatting, I used a repeat control to include the "td", "tr" and "thead" attributes Oliver listed in his blog post.
Let's use the classic example of blog context. In our domain we have the following scenarios: Users can write Posts. Posts must be cataloged at least in one Category. Posts can be described using Tags. Users can comment on Posts.
The four entities (Post, Category, Tag, Comment) are implemented as different aggregates because of I have not detected any rule for that an entity data should interfere in another. So, for each aggregate I will have one repository that represent it. Too, each aggregate reference others by his id.
Following CQRS, from this scenario I have deducted typical use cases that result on commands such as WriteNewPostCommand, PublishPostCommand, DeletePostCommand etc... along with their respective queries to get data from repositories. FindPostByIdQuery, FindTagByTagNameQuery, FindPostsByAuthorIdQuery etc...
Depending on which site of the app we are (backend or fronted) we will have queries more or less complex. So, if we are on the front page maybe we need build some widgets to get last comments, latest post of a category, etc... Queries that involve a simple Query object (few search criterias) and a QueryHandler very simple (a single repository as dependency on the handler class)
But in other places this queries can be more complex. In an admin panel we require to show in a table a relation that satisfy a complex search criteria. Might be interesting search posts by: author name (no id), categories names, tags name, publish date... Criterias that belongs to different aggregates and different repositories.
In addition, in our table of post we dont want to show the post along with author ID, or categories ID. We need to show all information (name user, avatar, category name, category icon etc).
My questions are:
At infrastructure layer, when we design repositories, the search methods (findAll, findById, findByCriterias...), should have return the corresponding entity referencing to all associations id's? I mean, If a have a method findPostById(uuid) or findPostByCustomFilter(filter), should return a post instance with a reference to all categories id it has, all tags id, and author id that it has? Or should my repo have some kind of method that populates a given post instance with the associations I want?
If I want to search posts created from 12/12/2014, written by John, and categorised on "News" and "Videos" categories and tags "sci-fi" and "adventure", and get the full details of each aggregate, how should create my Query and QueryHandler?
a) Create a Query with all my parameters (authorName, categoriesNames, TagsNames, if a want retrive User, Category, Tag association full detailed) and then his QueryHandler ensamble the different read models in a only one. Or...
b) Create different Queries (FindCategoryByName, FindTagByName, FindUserByName) and then my web controller calls them for later
call to FindPostQuery but now passing him the authorid, categoryid, tagid returned from the other queries?
The b) solution appear more clean but it seems me more expensive.
On the query side, there are no entities. You are free to populate your read models in any way suits your requirements best. Whatever data you need to display on (a part of) the screen, you put it in the read model. It's not the command side repositories that return these read models but specialized query side data access objects.
You mentioned "complex search criteria" -- I recommend you model it with a corresponding SearchCriteria object. This object would be technnology agnostic, but it would be passed to your Query side data access object that would know how to combine the criteria to build a lower level query for the specific data store it's targeted at.
With simple applications like this, it's easier to not get distracted by aggregates. Do event sourcing, subscribe to the events by one set of tables that is easy to query the way you want.
Another words, it sounds like you're main goal is to be able to query easily for the scenarios you describe. Start with that end goal. Now write your event handler to adjust your tables accordingly.
Start with events and the UI. Then everything else will fit easily. Google "Event Modeling" as it will help you formulate ideas sound what and how you want to build these style of applications.
I can see three problems in your approach and they need to be solved separately:
In CQRS the Queries are completely separate from the Commands. So, don't try to solve your queries with your Commands pipelines repositories. The point of CQRS is precisely to allow you to solve the commands and queries in very different ways, as they have very different requirements.
You mention DDD in the question title, but you don't mention your Bounded Contexts in the question itself. If you follow DDD, you'll most likely have more than one BC. For example, in your question, it could be that CategoryName and AuthorName belong to two different BCs, which are also different from the BC where the blog posts are. If that is the case and each BC properly owns its own data, the data that you want to search by and show in the UI will be stored potentially in different databases, therefore implementing a query in the DB with a join might not even be possible.
Searching and Reading data are two different concerns and can/should be solved differently. When you search, you get some search criteria (including sorting and paging) and the result is basically a list of IDs (authorIds, postIds, commentIds). When you Read data, you get one or more Ids and the result is one or more DTOs with all the required data properties. It is normal that you need to read data from multiple BCs to populate a single page, that's called UI composition.
So if we agree on these 3 points and especially focussing on point 3, I would suggest the following:
Figure out all the searches that you want to do and see if you can decompose them to simple searches by BC. For example, search blog posts by author name is a problem, because the author information could be in a different BC than the blog posts. So, why not implement a SearchAuthorByName in the Authors BC and then a SearchPostsByAuthorId in the Posts BC. You can do this from the Client itself or from the API. Doing it in the client gives the client a lot of flexibility because there are many ways a client can get an authorId (from a MyFavourites list, from a paginated list or from a search by name) and then get the posts by authorId is a separate operation. You can do the same by tags, categories and other things. The Post will have Ids, but not the extra details about those IDs.
Potentially, you might want more complicated searches. As long as the search criteria (including sorting fields) contain fields from a single BC, you can easily create a read model and execute the search there. Note that this is only for the search criteria. If the search result needs data from multiple BCs you can solve it with UI composition. But if the search criteria contain fields from multiple BCs, then you'll need some sort of Search engine capable of indexing data coming from multiple sources. This is especially evident if you want to do full-text search, search by categories, tags, etc. with large quantities of data. You will need to use some specialized service like Elastic Search and it won't belong to any of your existing BCs, it'll be like a supporting service.
From CQRS you will have a separeted Stack for Queries and Commands. Your query stack should represent a diferente module, namespace, dll or package at your project.
a) You will create one QueryModel and this query model will return whatever you need. If you are familiar with Entity Framework or NHibernate, you will create a Façade to hold this queries togheter, DbContext or Session.
b) You can create this separeted queries, but saying again, if you are familiar with any ORM your should return the set that represents the model, return every set as IQueryable and use LET (Linq Expression Trees) to make your Query stack more dynamic.
Using Entity Framework and C# for exemple:
public class QueryModelDatabase : DbContext, IQueryModelDatabase
{
public QueryModelDatabase() : base("dbname")
{
_products = base.Set<Product>();
_orders = base.Set<Order>();
}
private readonly DbSet<Order> _orders = null;
private readonly DbSet<Product> _products = null;
public IQueryable<Order> Orders
{
get { return this._orders.Include("Items").Include("Items.Product"); }
}
public IQueryable<Product> Products
{
get { return _products; }
}
}
Then you should do queries the way you need and return anything:
using (var db = new QueryModelDatabase())
{
var queryable = from o in db.Orders.Include(p => p.Items).Include("Details.Product")
where o.OrderId == orderId
select new OrderFoundViewModel
{
Id = o.OrderId,
State = o.State.ToString(),
Total = o.Total,
OrderDate = o.Date,
Details = o.Items
};
try
{
var o = queryable.First();
return o;
}
catch (InvalidOperationException)
{
return new OrderFoundViewModel();
}
}
i'm developing an asp.net mvc 5 web application using a page that is compose by around 10 module.
I'm implementing each module using a partialview with Html.action, that calling an action that get data from a web api
My doubt is about performance. Can Html.action destroy performance ?
Thank you
I think it depends upon the data and its dependency over the populated view
Html.Action
Action method is useful when the displaying data in the partial view
is independent from corresponding view model.For example : In a blog
to show category list on each and every page, we would like to use
Action method since the list of category is populated by the different
model.
#{Html.Action("Category","Home");}
Html.Partial
Partial method is useful used when the displaying data in the partial
view is already in the corresponding view model.For example : In a
blog to show comments of an article, we would like to use
RenderPartial method since an article information with comments are
already populated in the view model.
#Html.Partial("_Comments")
I am still new to sharepoint and would like to know if it is possible to make a query that works across several lists. My list looks like this
Customers (id, name and so forth)
Orders ( id, order number, customer and some additional info)
OrderItems (id, name, price, description and so on)
I would like to create a view that will display the OrderItems grouped by Order which again will be grouped by Customer.
In pure .net code that is pretty easy but is it possible to implement it only using sharepoint lists?
Without custom code or third party components you would have only a few options. Using SharePoint Designer to create a Data View or creating a custom Query with some complex CAML which I'm not even sure is entirely possible.
Personally I would look more towards using Master Detail functionality using a combination of web part connections and filtering. By activating Enterprise features you have available a number of Filter Web Parts that should be able to be combined to filter lists to selected values.
Personally I have gone with custom code to bring back list data based on queries and then used the GetDataTable() method of the SPListItemCollection object. Once you have the list items in DataTables you have numerouse ways to sort filter and aggregate the information.
I should add to this that there is a great article on displaying information from a dataset using the SPGridView and SPMenuField. Once you have your DataTables you could establish relationships in a dataset to display the information using these controls:
http://blogs.msdn.com/powlo/archive/2007/02/25/displaying-custom-data-through-sharepoint-lists-using-spgridview-and-spmenufield.aspx
Connected web parts can do this...
I think SPD can do that.
If you do not want get yourself dirty, take a look at SharePoint List Collection, which is perfect to you.