The main question is how to specify customized views. For Xml, I'm inclined to use a standardized set of elements for cards and links as implemented and allow for xslt based views (i.e. send supporting custom views as xslt scripts that function as stylesheets). This xslt (or similar) processing could also be server side, and we could use something like Rabl for a similar role in json (taking the generic objects and using the object names and attributes expected by the client (customized).
My sense is that the default xml/json data should be, essentially, a standard wagn export format. so including stuff like classes and such seem a bit much. I do think it would be nice to include an "origin" (or some similarly named) key whose value is the url for the card (html) from which the export originated.
I'm inclined to say the fields should predominantly use keys not ids, because any given import will be likely to use the same names or variants thereof, but the ids may need to be entirely different.
--Ethan McCutchen.....2012-09-28 21:27:43 +0000
I'm going to improve the examples. To outline what I'm planning, a couple of links I'm still exploring: JQuery plugins: jstree and
--Gerry Gleason.....2012-10-08 15:31:45 +0000
So, the comment is about row views. Like a line view (closed), but meant to be a row in a table/grid. In Json, I'd want to render a type with a template (*content rule) as named attributes to the data model rather than as child elements or an array, etc. In Html, we may use a table row format. Do we need a distinct templete, so a *row rule?
--Gerry Gleason.....2012-10-10 15:05:21 +0000
re row views, I have a proposal coming soon for that; I don't think we have to resort to new rules. (In fact, I think the solution will have a ton of other uses)
--Ethan McCutchen.....2013-03-11 22:53:13 +0000
re question 1, I added a stab above in Proposal 2. With Proposal 1 (which isn't terribly different), I'd want to see how the recursion actually works.
--Ethan McCutchen.....2013-03-12 03:23:26 +0000
This card is not showing up in Ticket and I did clear the cache. I just changed the type to Ticket (from Idea), that should work, right?
--Gerry Gleason.....2013-03-13 20:58:25 +0000
I'm not sure I'm following how you want to "see how the recursion works". Is that about clarifying the example, or describing how it would work?
--Gerry Gleason.....2013-03-13 21:51:15 +0000
Your Proposal 2 doesn't really show how it would handle multiple cards, like a deck or pack as a single object. Would you just have an Array of those? Seems reasonable, just asking.
--Gerry Gleason.....2013-03-13 21:53:07 +0000
Finally noticed the big difference here. My form (P1) is all parsed and the inclusions and links are objects. It isn't what we want for export, but it could be what we want for an API that is used by advanced javascript enhancements. The point is that I don't want to have to parse the inclusions in javascript, I want that on the server side.
Do you think that makes any sense for UX based use cases?
--Gerry Gleason.....2013-03-13 21:57:34 +0000
Lots of good questions. Some thoughts:
1. yes, this should be a ticket. If we keep the scope small, it might go 1.11, but 1.12 is the better bet.
2. by recursion, I would expect to see something more fractal. In Proposal 1 I don't see any patterns recurring further down the tree. In Proposal 2, you see :card and :view twice as an attempt to show how recursion might work. Basically, it probably just boils down to having some example inclusions in addition to links.
3. With the wagn web api, we often view many cards, but we always use one as the window. (Eg, you go to a named search card to see a list of cards returned by that card). That is what I would propose we do for this rep as well. So mulitiple cards would look something like {:card=>{:name=>'my search'}, :view=>{:parts=>[{(card1)},{(card2)},{(card3)},{(card4)}]}}
4. P2 had an attempt to show both parsed and unparsed results. In the use cases we listed export, which would often benefit from unparsed, particularly if exporting to another Wagn. I was using "content" (part of the card object) to refer to the unparsed portion and "parts" to refer to the parse part.
I really think P2 is just a slightly crisper version of P1. Really P1 v2 :). I like that it maps a little more cleanly to Wagn structures with fields like "view" and "content", and that it shaves off a little fat like "attributes", which seems redundant to me.
--Ethan McCutchen.....2013-03-14 02:46:39 +0000