This project is read-only.

Retrieving connected contentItems advise

Nov 13, 2011 at 1:21 PM

i'm very impressed with your mechanics and media modules. outstanding! Unfortunaly it's quite confusing to start with them without documentation but i managed to understand the workings.

Currently i'm busy with a n-n relationship between users and teams and i want to custom retrieve the user connected teams. What is the best way to retrieve them? I don't want to use the default rendering because i have to calculations (for example how many connected teams,etc).

Is something like this the best way?:

_orchardServices.ContentManager.Query<ConnectorPart, ConnectorPartRecord>().Where(s => s.LeftContentItem.Id == userPart.Id).List();

or is there a better way to do this?

Nov 14, 2011 at 9:19 AM
Edited Nov 14, 2011 at 9:30 AM

Thanks! Yes, documentation is the biggest problem at this point - I'm using the modules very successfully for a variety of things, it's really quick and easy to mock out fairly complex data models, but there are lots of features that probably only I'm aware of.

The API provides an easy way to pull out relationships. If you import IMechanicsService then you can call IMechanicsService.Connectors(userPart) and this gives you a Queryable - actually it just runs the same query you described.

However, there is an even better way to display a count; Mechanics already provides a shape which displays a count (and since it uses a query that already exists thru the User rendering, it should be more efficient this way, rather than manually creating your own query).

So, try adding this into your Placement.info, it should give you the count for free:

 

    <Match ContentType="User">
      <!-- Show count -->
      <Place Socket_Connectors_Count="Connectors:before"></Place>
      <!-- Hide connectors-->
      <Place Connector="-"></Place>
    </Match>

Finally, you can override Socket.Connectors.Count.cshtml (from Downplay.Mechanics\Views) to customise the rendering.

Nov 14, 2011 at 9:57 AM

yes i think many people don't understand your modules so they don't use it and create relations,etc manually. That's sad because there are really powerfull do they need some ui improvements at some places. For example when you have n-n relations with users and you have more then 1000 users you will get more then 1000 checkboxes in the editor for the connected item.

have you already thought about some implementation/coupling for multiple picker fields? It would be nice (don't know if possible) if you can create some generic solution for the picker fields like (image picker field) so you can pick multiple values. The connection/relations could be handled by you Mechanics so the pickers will automatically support multiple values instead of 1. This would be very nice because mosts field modules only support one picked value.

Nov 14, 2011 at 10:00 AM

I just had a check ... actually that placement won't work. I get around this in one of the "Identity" examples by implementing a SocketHandler to change the DisplayType for a particular type of socket, so I can Match DisplayType="Directory".

But, I'm just making some changes that will correctly bind the ContentType so you can use it as above. Then there are further changes coming which will bind entirely new options into Match clauses, so you'll be able to do things like: <Match ContentType="User" Socket="UserToTeam"> - that should be available in the next couple of days.

Nov 14, 2011 at 10:06 AM
Znowman wrote:

yes i think many people don't understand your modules so they don't use it and create relations,etc manually. That's sad because there are really powerfull do they need some ui improvements at some places. For example when you have n-n relations with users and you have more then 1000 users you will get more then 1000 checkboxes in the editor for the connected item.

have you already thought about some implementation/coupling for multiple picker fields? It would be nice (don't know if possible) if you can create some generic solution for the picker fields like (image picker field) so you can pick multiple values. The connection/relations could be handled by you Mechanics so the pickers will automatically support multiple values instead of 1. This would be very nice because mosts field modules only support one picked value.

My plan has always been to have an AJAX search box for scenarios where there are, say, >10 items available. I recently started working on this in the 'lens' branch. This will be an awesome feature that can also replace Orchard's default search.

Originally I was going to implement a "ContentField" that leveraged mechanics, however I gradually realised there's actually no point. The Mechanics UI provides something that looks exactly like a field, you just have to create a new connector type any time you want a new "field". For instance in one of my websites I needed a BackgroundImage field on the Page content type. So I just created a BackgroundImage connector with 1:1 multiplicity and instantly there's a field for it.

Finally, I'm also planning to further develop "mini editors" in the UI (there are already some examples of this, for instance how you can alter the title or sequence of the connectors directly within the parent form). The implications of this would be things like a file upload field (which would connect through to media garden), or a small form for adding other new items, making it really easy to create and attach new content from the one page. Again this will use AJAX to be very quick and friendly.

Nov 14, 2011 at 10:10 AM
randompete wrote:

The API provides an easy way to pull out relationships. If you import IMechanicsService then you can call IMechanicsService.Connectors(userPart) and this gives you a Queryable - actually it just runs the same query you described.

I made a small mistake above. You should instead call IMechanicsService.Connectors(userPart,"UserToTeam") - it's an extension method, it will query only a specific connector type, instead of return all types of connectors.

Nov 14, 2011 at 10:21 AM

The latest commit now supports Match ContentType.