sharks

get started

concepts

features

syntax

 

monkeys

intro

mods

REST API

 

platypuses

github

blueprints

tickets

 

everyone

support

ideas

contact

license

 

 
 

Wagn Rules+old discussion

help edit space_dashboard

 

I mostly like it. We have discussed the idea that the Set hierarchy that is implemented in the Pattern class and is the core of what this is all about are a lot like Name Contexts that are common to many programming and systems languages. I accept that the term context is overused, and endorse using the term Pattern (Wagn Pattern in a more general context) to refer specifically to this name context pattern.

 

(Aside: if the API provides a way to add new Sets to the Pattern lookups, I want to call that a "Pattern Extension" or "Extended Pattern", etc.)

 

I also like how we can be more specific, so the version example is a "Self View Pattern" (or "Solo View Pattern" as it is called in the code).

  --Gerry Gleason.....Thu Feb 24 04:11:00 -0800 2011

In light of this, shouldn't define_view => view_pattern and action_pattern for actions? Have to think about alias, I think it needs to stay alias_view (and alias_action if we need it, would alias_set be useful, or what would that be like?).

  --Gerry Gleason.....Thu Feb 24 04:30:46 -0800 2011

What fits for me about what Ethan's written is that Sets are like nouns, and Settings, Views, and Actions are all like verbs, and I think having terminology that ties together the latter group of things (which seems likely to grow over time) is a good thing. As I said in email, I think the language here is to geeky for many Wagneers, just lack the time at this moment to offer specifics or a rewrite.

  --John Abbe.....Thu Feb 24 11:42:06 -0800 2011

When you "add new Sets to the Pattern lookups", wouldn't it make more sense call that a "Set Extension" or "Extended Set"? What I'm understanding Ethan to be proposing is that Pattern refer to a Set plus a Setting, View or Action.

  --John Abbe.....Thu Feb 24 11:44:02 -0800 2011

The whole point of this discussion is that Pattern refers not to a single Set, but to the search pattern of all the sets that apply to a card. It would be adding a Set card. A Set is a single Pattern class whereas the Pattern is the entire context search pattern that it is a part of.

  --Gerry Gleason.....Thu Feb 24 20:00:00 -0800 2011

I was not saying a Pattern refers to a single Set. I understand Ethan to be suggesting that we use Pattern to refer to any Set combined with either a Setting, a View or an Action.

 

I interpreted Gerry's "add new Sets to the Pattern lookups" to mean adding a new kind of Set, e.g., type+type, which is why it made more sense to me to refer to that as a "Set Extension" or "Extended Set". Obviously it would extend the power of Patterns in general, but it seems more precise to narrow it down to the part of Patterns that it's expanding. Could include both, say, "Pattern Set Extension"?. Or maybe I misunderstood what you meant by "add new Sets to the Pattern lookups"?

 

I have a feeling that this would be much easier to sort out on a live call, so I'm hereby lump this topic in with my request for a call on vocabulary for the API...

  --John Abbe.....Thu Feb 24 21:07:32 -0800 2011

 

I somehow hadn't seen this discussion until now. Gerry, I hadn't intended to use pattern to mean "the search pattern of all the sets that apply to a card". That seems much closer to the scoping, context, etc. conversation. I was saying that a Pattern is, as John was saying, a specific configuration of a setting, view, or action, each of which is necessarily set-based. Can you point me to what I said in the blog post that led to that confusion?

 

Re method names, I would still lean towards "define_view" and "define_action", because I think the verb is helpful. It's true that views and actions definitions are both patterns, so we could correctly call them "define_view_pattern" and "define_action_pattern", but that sounds a little bit to me like calling Finn a "baby human" and calling you guys "men humans". Accurate, but a bit overly explicit and awkward :)

 

But to John's point, I think a vocabulary discussion is long overdue, and I'd like to suggest that we make this our deliverable for a Thursday night "higher level" team call. Will send more soon.

 

(btw, I started reworking stuff above but only really got to the part that needed it least. I won't be publishing this until after that call.)

  --Ethan McCutchen.....Sun Mar 06 09:29:11 -0800 2011

I started rewriting, but then realized some things I wasn't clear about, and anyway knew that wasn't your preferred form of input, Ethan.

 

I was torn in two directions while writing - one, wanting to keep it simple, understandable to people who aren't super-geeky, maybe even to non-Wagneers. On the other hand, wanting to be more clear and explicit to geeks. My sense is that what's already here is trying too hard to do both. So I stopped partway through editing a long version of this, aimed at somewhat geeky people:

help edit space_dashboard

(Not publishing this blog without more buy-in on this vocabulary)

 

Wagn's "everything-is-a-Card" idea is impressively fertile. Its latest offspring? "Every configuration is a Pattern."

 

Even if you're just getting started with Wagn, you have some understanding of "Cards".You understand that by "everything is a card", we mean that almost every unique chunk of information on Wagn is in a card, whether that information is text, or an image, a user, a search, a setting, a number, etc.

 

 

If you've gotten serious about exploring Wagn, you also know that Sets are groups of cards you can configure with Settings. The idea is that you can apply settings like layouts, templates, captchas, help text, etc., to a specific card, or to various more general sets of cards.

 

But you probably haven't heard us use the term "Pattern" much. It's new.  

 

"Pattern" refers to any Set and a configuration applied to it. Right now there is only that one kind of Pattern: Setting Patterns.  With Decko 1.0 and our new Modules API, there will be two new kinds: View Patterns, and Action Patterns.

 

 

Setting Patterns

 

Settings 

 

For example, one Pattern common to all Wagns is the layout configuration controlling how pages are laid out — a bar with Home, Recent etc. at the top, logo and sidebar on the right, etc. This layout is specified by applying the *layout Setting to the Set of all cards. Whenever you apply a Setting to a Set, you're creating a new Pattern. Specifically, you're creating a "Setting Pattern."

 

 

View Patterns

 

"View Patterns" configure card views for a specific Set of cards. For example, when you edit an Image card, you get a different kind of editor from when you edit, say, a RichText card. (You get an upload button to upload an image.) That editor is configured by applying a special "editor" view for the Set of Image cards — in terms of cards, something like *image+*type+*editview will Point to a card representing the Image editor.

 

As an even simpler example of a View Pattern, consider the *version card, which lets you view Wagn's current version.  I'll include it here:

Currently, the *version card gets special treatment directly in Wagn's code. With the Module API in place, we will apply a special view (on that ). We can now make that work automatically using the Module API by configuring the "raw" content of the Set of cards that has just one card in it: *version.

 

 

Action Patterns

 

The third type of Pattern, "Action Patterns", configures actions that are triggered by special events (creating, updating, deleting, etc) for a Set of cards.  For example, when someone edits a Support Ticket card (a member of a type-based Set), you can automatically add that user to the "watch" list.  Or when someone signs up (creates an Account Request card) and correctly lists the secret passcode, you can automatically give them the "Special Friend" Role.  Or, more prosaically, when someone adds a Number Card, you can make sure it's really a number or else disallow it.

 

I should clarify that when I say the Module API lets you add View Patterns and Action Patterns, that's actually pretty much all it does (for now at least).  We think just those two kinds of Patterns are going to be pretty darned powerful.

 

What do you think?  Does the "everything-is-a-pattern" approach to configuration have as much potential as the "everything-is-a-card" approach to data storage?

 

...and shifted over to drafting a short version, aimed at a general audience:

help edit space_dashboard

Wagn's "everything-is-a-card" philosophy is impressively fertile. Its latest offspring? "Every configuration is a Pattern."

 

By "everything is a card", we mean that every chunk of information in Wagn is in a card, whether that information is text, or an image, a user profile, a search, a setting, a number, etc. If you've gotten serious about exploring Wagn, you already know that Sets are groups of cards you can configure with Settings. The idea is that you can apply settings — such as having a table of contents, or a form, or help text — to a specific card or to more general sets of cards.

 

"Every configuration is a Pattern" generalizes this idea. Applying a setting to a set of cards is one kind of Pattern, a "Setting Pattern". With the new Modules API we are adding two new kinds of things you can apply to sets of cards: Views, and Actions. Applying a view to a set of cards will be a "View Pattern", and applying an action to a set of cards will be an "Action Pattern." So a Pattern is any Set-based configuration.

 

For example, currently when you edit an Image card you're offered an upload button. This different handling from the way Basic cards are edited has only been apparent (and configurable) in Wagn's code. With the new system, this will be articulated as a View Pattern, applying an "ImageEditor" card to the Set of all Image cards. Action Patterns would work quite similarly: when someone edits a discussion card, you might want to automatically add that user to the watch list for that card. This would be configured by applying a "NotifyUser" card to the Set of all cards that end "+discussion".

 

Any Wagneer will be able to create Patterns, applying Views and Actions in their Wagn to any set of cards. The Wagn team will develop and configure all of the Views and Actions (such as ImageView) needed for Wagn to keep working just as it does now. Adding new ones (such as NotifyUser, or a more powerful image uploader) will require a programmer, but they won't have to dig too deeply into Wagn's code — that's the whole point of the Module API, making it easy to extend the power of Wagn.

 

We think just these two new kinds of Patterns are going to be pretty darned powerful. What do you think?  Does the "everything-is-a-pattern" approach to configuration have as much potential as the "everything-is-a-card" approach to data storage?

For the blog entry, I think short is good, perhaps linking to a longer, geekier white paper.

 

Will view and action patterns look like this?

  • image+*type+*view — Pointer to a built in card of type View, in this case one which assumes the content of cards in its set will be a URL to an image, and displays it
  • address+*right+*edit — Pointer to one or more cards of type Action, in this case for example it could be on which causes Wagn to run a sync with an external contacts database.

If so, there's really nothing new here except language, right? I mean, they look and act just like settings. Or am I missing something?

  --John Abbe.....Sun Mar 06 13:51:15 -0800 2011

Well, I suppose this is at least helpful in the sense that I see from what you're describing that you're not getting what I was blogging about. You're just talking about more settings. View Patterns and Action Patterns are, at present, a code phenomenon, not involving a setting card. I was going to be more explicit about that as I finished the blog.

 

Seriously, you'd save yourself a lot of time just asking clarifying questions rather than attempting rewrites. I know you're trying to help, but to ask explicitly: please don't rewrite my blog posts. Not all content is communal.

 

There will be more discussion around the API for geek audiences. The Pattern stuff is for broader audiences -- specifically for wagneers who have some understanding of sets/settings. I gather that you think that some of it is too geeky for that audience. I think I need to flesh out the Action Patterns and View Patterns, but the rest should be pretty approachable to them.

  --Ethan McCutchen.....Sun Mar 06 16:27:02 -0800 2011

Rewriting is often much easier for me. I tried to respect your request by doing it on a separate card, and then just writing my resulting comments/questions here. You can think of the rewrites as source material that you can ignore if you like.

 

I'll hold off on further input until I'm clearer (hopefully after Thursday's call) how Views and Actions work, and what you're trying to communicate to people about them.

  --John Abbe.....Sun Mar 06 18:50:14 -0800 2011

My previous comment was brought to you by the letters "P","M", and "S".

  --Ethan McCutchen.....Mon Mar 07 10:11:16 -0800 2011

Thx, that helps (seriously).

  --John Abbe.....Mon Mar 07 12:14:25 -0800 2011

"Will view and action patterns look like this?"

 

No, they don't actually have cards, more like (in ruby code):

declare_view(:raw, :type=>"image") { ruby code }

 

:raw being the view of what is actually stored in the card (it's 'content' with no processing), and then there is a whole structure of more complex views built on this base. With the actions, it will likely be CRUD plus (create, read, update, delete, and more if needed), and again it will be declarations in the code.

 

We may create cards like that in the future, but for now they don't exist. If we do have settings for this, maybe image+*type+*raw contains the ruby code in the block, and has a special cardtype (maybe just Ruby).

  --Gerry Gleason.....Sat Mar 12 03:37:53 -0800 2011

Re: Pattern Extension, this illustrates that a bit. image+*type and :type=>"image" are connected to the same pattern. If the API has a way of extending that (and I'm not saying it should, adding this maybe should be 'core').

 

The example of '*has right' I mentioned that relates to a generalized card version of "extensions" that I was talking about on the call. foo+*has right and :has_right=>'foo' would be an extension to Patterns, which are more than Sets though closely related.

  --Gerry Gleason.....Sat Mar 12 03:45:52 -0800 2011