Ticket+recent inclusion changes
Argh, seems okay here but was a problem on Early Steps. Will test further. Hrm, on the other hand, it is resulting in a premature end-of-card. (scroll down)
lorem ipsum
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat.
Click on Add Chocolate chop cookies here:
Broken:
http://test.dwagn.org/card/related/Menu
Card menus are the primary interface for editing and configuring cards. They are designed to be minimally intrusive when casually reading but convenient and powerful when engaging more actively.
Example
The default Decko menu icon (and the icon used on decko.org) is a little gear that looks like this:
view (menu link) not supported for menus+example
This same gear appears in the upper right corner of this page, where it represents an active menu. To open up the dropdown, just mouse over the icon (or tap on it if you're on a mobile device).
How To
Navigate
The following items can appear on the menu, though few cards will have all of them:
- edit - only appears if user has update permission. submenus:
- content
- name
- type
- structure (on cards with *structure rule)
- delete (where permitted)
- view - always appears. submenus:
- refresh (reloads without reloading page)
- page (loads card's page)
- type (loads type card's page)
- history
- structure (on cards with *structure rule)
- discuss - appears when users is permitted to read or comment on +*discussion card
- advanced - always appears. this is the most important menu item for configuration (wagneering). It has many submenus and sub-submenus. (to be discussed)
- follow - appears when user is logged in and card is not new
- account - appears when card is "accounted" (represents a Wagn account). submenus:
- details (email, password, roles, etc)
- created (all cards created by this account)
- edited (all cards edited by this account)
Include
At present, only cards in "open" and "labeled" views display the menu by default. For example, here is the card named "Apple". Note the menu at the upper right, on rollover:
You can count how many seeds are in an apple, but you can't count how many apples are in a seed.
You can count how many seeds are in an apple, but you can't count how many apples are in a seed.
However, any view with a card header can also display the menu using the "show" directive (see Nest Syntax).
Apple
You can count how many seeds are in an apple, but you can't count how many apples are in a seed.Apple
You can count how many seeds are in an apple, but you can't count how many apples are in a seed.
Though it's not frequently used on its own, "menu" itself is a view and can be used anywhere on a card. Note that the following generates a functional menu for this card ( menus+howto):
Tips
- In almost all cases, clicking on an item that has submenus is equivalent to clicking on the first item in the submenu. Eg, clicking "edit" is the same as clicking "edit > content".
- Every item on the menu has its own url. You can use standard mouse/keyboard shortcuts to open any link in a menu in a new tab (eg control-click or command-click).
- Similarly, you can use standard shortcuts to copy the url (eg right click).
Discussion
Not broken:
Not broken:
When you sign out, you shouldn't see private cards here, but you do. If you open the card it goes away, but it shouldn't be visible even in closed view.
These examples illustrate the issue behavior describe above:
as link: Wagn 0.10 and beyond
as inclusion (view:link): Wagn 0.10 and beyond
Before doing this, it might be worth considering an even more powerful/general approach to sorting. Imagine each User has a Pointer to their high school, each of which has an address, then i'd like to be able to sort a bunch of Users by their high school's city. Again, sorting by more than one is much better (country, state/province, city).
Also see:
view (line) not supported for sort by content
as per:
from initial design: CQL+Design+braindump, CQL+Design+questions
Design for multiple values
Short property syntax
The translation from single to multiple of our current simple syntax is clear:
PROPERTY => VALUE (implies operator is :eq)
would look like this in the new system:
PROPERTY =>['in', VALUE1, VALUE2, ...]
eg. :name => [:in, 'Lewis', 'John', 'Bryan']
eg. :type => [:in, 'User', 'Company']
Note there's no need for an "and" operator here, because no property can be equal to more than one value. For example it wouldn't make sense to say "give me all the cards that have the type User and the type Company".
(this much has been implemented)
OPERATOR => VALUE (implies property is :content)
would look like this:
OPERATOR => [:in, VALUE1, VALUE2, ...]
eg. :eq => [:in, 'open', 'in progress', 'coded']
in this case, there could be conceptual need for multiple operators and hence an "and" operator. Eg. > 5 and < 8. We don't have use cases here yet. Not sure what the best syntax would be to go with :in. Perhaps :all? :is?
Full property syntax
The longer property syntax is a bit more involved. We're thinking this:
PROPERTY => [OPERATOR, VALUE]
would look like this
PROPERTY => [in/all, [OPERATOR1, VALUE1], [OPERATOR2, VALUE2], ... ]
eg. :content => [:all, [:match=>'Lewis], [:ne=>'Jerry Lewis']]
Relationship syntax
As of yet, there have not been a lot of use cases for relationships using multiple card definitions, since the definitions already support and's and or's themselves. For example, the following would be the obvious syntax:
RELATIONSHIP => CARD_DEF
RELATIONSHIP => [in/all, CARD_DEF1, CARD_DEF2, ...]
eg. :refer_to => [:in, 'Lewis', {:type=>'Company'}]
but you can already accomplish that example at least by doing this:
:refer_to=>{:or=>['Lewis', {:type=>'Company'}]}
Plus Cards
So the plus cards are different, because arrays already have special significance:
:plus => [A,B]
and because since plus cards are the basis of our representational system, we definitely need to be able to handle multiple plusses. (For example, open tickets with high priority). so, we figure if there are more than two elements in the array, it necessarily means that the first one is an operator:
:plus => [ :in, [A,B], [A1,B1] ]
In that case, each element after the operator is treated like a normal plus arg, which may be an array or shortcut.
So you could say, for example:
:plus => [ :all, "dog", "cat"]
which is all cards connected both to dog and to cat. It's equivalent to:
:plus => [:all, ["dog", {}], ["cat", {}] ]
IF we solved the multiple key problem, we could express and and or with the existing pieces:
{ :content=>[:match, "Ethan"], :content=>[:match,"Scrabble"] } --parts of cards defs are joined with 'AND' by default
{ :or=>{ :content=>[:match,"Ethan"], :content=>[:match,"Scrabble"]}
it would be easy to provide
{ :and=>{ ... }} for symmetry, which would essentially be a no-op
--Lewis Hoffman.....Wed Feb 20 09:52:38 PST 2008
note that for the current :or to work, we have to handle multiple key problem internally, which we do by having things like { id:1=>(..), id:2=>(..) }.
--Lewis Hoffman.....Wed Feb 20 10:02:26 PST 2008
also want to point out that this could ultimately be taken further to include some cool nesting:
[:and, A, B, [:or, C, D, E] ]
--Ethan McCutchen.....Wed Sep 17 13:12:22 -0700 2008