Using webservices / IPSContentWs > PSCoreItem I am able to get all the fields of a certain content type. However, I do not get them in any particular order. What I would like is the fields to be returned in the same way that is ordered in workbench (or in the regular content editor when adding an item of that content type). Is there a method that I am missing here to return the fields in the defined order (or is there another class I should be using?.. I looked at IPSContentTypeMgr but that doesn’t seem to help).
Workbench makes a SOAP request to http://rhythmyx:9992/Rhythmyx/Designer [HTTP Basic authorization, PS-Request-Type: design-objectstore-app-load]. You can see an example SOAP request captured in our instance by visiting this gist. The XML response encapsulates the content type’s ObjectStore XML (i.e. /path/to/Rhythmyx/ObjectStore/psx_cerffNavon.xml) within the PSXDesignAppLoadResults element. You can find the field arrangement in the PSXUIDefinition node tree.
Definitely not a solution, but we know where the field arrangement is stored.
Can we get ObjectStore data from the available Web Services API?
Yup, I thought the objectstore would have the field ordering… but was really hoping there was a way to get that info through the API… After all, how do they expect us to get rid of the ephox editor if we can’t create the fields in a specific order?
I’m using the API to create a JSP that allows a user to edit the body (or any other) field (Right now, the issue is that there is 8k table rows in that field and it takes ephox 10+ minutes to process it without any guarantees that it will succeed… ie. sometimes it does, other times it doesn’t). In addition to increasing the maxPostSize in the server.xml (yes, the post content is over 2MB for that field), I’m using tinyMCE editor for displaying that field. Initial testing has it posting and updating the item in under 20 seconds so I was just wondering if I could make it look like a “normal editor” so that other fields could also be displayed and edited (and not just a single field…i would like the fields to be displayed automatically and in the correct order)… Of course the warning of “no inline linking of content or inline templates” via this method has been given…
Do you have any concerns with using the workbench SOAP call or would you prefer that PSCoreItem be extended in the API to include a field arrangement map? Are you going to use your JSP to replace the existing content editor or does it standalone outside your Rhythmyx environment? When does Ephox start processing your the 8k rows in the field? (As an exit extension?)
I’ve been debating whether to create a ControlType for TinyMCE as well as the necessary extensions to handle inline variants and links.
I’m sure someone at Percussion would be happy if you develop tinymce extensions to handle cms inline templates and links :).
I would prefer that the API be extended to provide the arrangement. Using workbench soap seems like too much of a hack (yes, what I am doing is one too, but there has to be a line… in the sand…that shifts and is wiped away…but a line nonetheless ).
Ephox starts processing table rows immediately as you insert them. So it isn’t a matter of post extension, it is just the way that Ephox goes from say html view of 8k rows to “normal” WYSIWYG view. I have tried pasting the same code to the EditLive demo site with similar results (So this is an Ephox “feature”…probably parsing the table in some great way… you would need to increase the JVM size too as it can easily go above 500 mb as it keeps chugging away at something).
For our purposes, it is a JSP page that will appear as a menu entry (similar to a “publish now”). As mentioned prior, it does work with a single known field, but it would be nice to make it “generic”.
I have been researching WYSIWYG editors to see which one delivers a better experience than what we currently have. TinyMCE has been on the list for a while.
I agree with your preference to have the API extended. Would the best solution be to provide the fields in the correct order or provide a separate method that delivers the field order?
Somehow I misunderstood your statement to be that Ephox was processing all the field rows in the Rhythmyx repository, but it is all much clearer now after some sleep. You are right that Ephox quickly hits a resource limit attempting to provide a WYSIWYG environment for large objects (i.e. a table with 8k rows). Is there a valid reason to have such a large table in EditLive?
To address the content concern first… While I don’t think it is great to have such a large table, the technology should not prevent us from having / doing it. I think this is especially true when we say that the field can hold over 2 gb of data, but just having over 2mb crashes the editor… or at least makes it completely unusable. In terms of the actual content, we use it to display lists of things / people /places (ie. http://www.vtnews.vt.edu/awards/students/deans-list/spring-2011.html). You could argue that it would be best served to develop a separate app, but the javascript data table works fairly well for us (once we get the table as content in the system… and really why develop another app when we don’t need it?).
I looked at TinyMCE simply because Ephox (or it’s parent company) had bought it and I figured that eventually Percussion would get around to leveraging their contacts to see what they can do for CM System.
While it would be nice if the returned object had the fields in the correct order, I think the better way would be to have a separate method that returns the field order. I am not a WSDL guru by any means so I’m not sure if the change in the WSDL to dictate field ordering of an older method breaks backwards compatibility.
I looked at TinyMCE simply because Ephox (or it’s parent company) had bought it and I figured that eventually Percussion would get around to leveraging their contacts to see what they can do for CM System.
CM1 already has TinyMCE, right?
While it would be nice if the returned object had the fields in the correct order, I think the better way would be to have a separate method that returns the field order. I am not a WSDL guru by any means so I’m not sure if the change in the WSDL to dictate field ordering of an older method breaks backwards compatibility.
I think I read that somewhere or someone told me… I don’t have any first hand experience. It would make sense for them to stay with the same “vendor.” But then again, there are other things that should make sense…
Yes, 7.3…riiiight… I was hoping there was something I missed :(.
What you are looking for is the PSItemDefinition object this is in the public JavaDoc. You can access this through the ContentWs though the loadContentTypes method. If you are accessing internally you can also use the singleton item definition manager PSItemDefManager.getInstance()
Excellent! The fields returned from LoadContentTypes are in the correct order. Using that in conjunction with CreateItems allows me to display the field names and their labels (LoadContentTypes does not return the label of the fields, just the name).
Thanks!
So I guess the follow up question would be how do I get the label of the content type (using webservices…not the Java API)? Neither of the above two methods returns the actual Label (just the name) of the Content Type…
PSItemDefManager has a method getField Label that can be used.
public String getFieldLabel(long ctypeId, String fieldName)
The structure of these objects is like the XML in the ObjectStore directory and is a little convoluted. PSField is stored in one location in the xml that maps to the data type and column, then there is a separate display mapping section which has the control and displayname etc… This method in PSItemDefManager hides some of this complexity.
