Pattern Cards+as DSL
Based on the outline in Hands of Cards, I am reworking the DSL part, I'll leave the original below and we can delete it when we have harvested the parts we still want. The important move is the treatment of the DSL as distinct from patterns, but important for their definition. Rather than try to attach these definitions as plus cards to patterns, we move them out to separate namespaces (proposed as System+Patterns+<class>, System+Type+<cardtype> or System+Hook+<hookname> and so on).
Pattern Usage
Transclusion syntax within the DSL can be used so that the DSL can refer to <pattern>+<tag> if the tag is a virtual card (and maybe a virtual card is just another pattern/search card) I can then fetch a plus card that returns a set of pointers to other cards. With this way of defining WADL cards, the WADL cards have to connect the tags we want to use with the patterns as well as the code to interpret that tag data for a particular hook or feature. The WADL code can use these plus cards however it wants, the set of pointer might be theset of roles that are allowed to do something like this:
auth :role -> :edit_ok, :roles -> # :roles could be defaulted this way from :role
Another declaration could tell it to use an Allow/Deny protocol in a particular order from all the matching patterns that have +auth attributes attached. Same thing for templates. The WADL code can use any information at its disposal to customize each step in the controller/view flow as well as defining what those steps are, and all of this can use the pattern system. It may be that patterns are just search cards that are used by WADL declared processes.
Module Support
I think Lewis mentioned somewhere in the discussion that we want to use the rails support for automatically loading code when it is reference. I agree and I think I already have said that we need to use as many of the best practices of our language communities, and continue to strive to use them better to achieve our goals of extremely flexible module support. We want to achieve this (load by reference) with WADL too, so that I just have to refer to some publicly defined symbols that are associated with the modules I want, and I automatically get it loaded and dependencies generated for any gems or cardsets (Decks?) that may need to be loaded.
Admin tools should be able to assist a Wagneer in choosing well qualified modules that work well together according to their project requirements. At the WADL level we want to just specify the dependencies and our choices for how to satisfy the ones that have options or are completely options, but I can imagine Wagn based tools to access the distributed repository of these resources. We don't want to specify this here, just to note that we want to support this kind of wagneering in the post 2.0 network of Wagn operators and developers and help create key repositories for this distributed network as it emerges.
WagN as WADL
I think it will be a key exercise as we define Wagn 2.0 to use the requirements of implementing features and functions from Wagn in WADL. I want to be able to toss around proposed ways of coding and organizing the core components. It has been very helpful to me to look through the current code and think about what parts I want to have in WADL, what parts go into Card Type modules, etc. We need to start from the application layout, and how it connects with other controllers (account, and others), and if some of these even can go into card modules so they are now card level rather than application level.
I think we want to define the basic flows where missing cards get redirected to "new", with the hooks for authorization, rendering actions and view parameters all in the mix. Detail and shared behavior can be coded in the modules to keep the WADL code brief and clear as a DSL should be.
Namespace Card Type Module
Added this as an independent idea that could be added before all the 2.0 work: Namespace Cardtype for Mounting Wagns. The basic ideas is the <namespace card>+<plus path> represents mounting an independent resource in the local namespace. At first I was thinking <namespace>:<card>, but then thought why use a different separator, keep a single namespace syntax. Then I realized how a cardtype could be used to add this cleanly.
Old Material:
Rather than add this as a discussion to the basic patern ovrview, I'm adding a card and some of my discussion from the list as a separate item. This part can be external to cards, but it could also replace the search card, with search becoming a restricted subset of this language. Now having read much of the material below, I this actually represents a more general solution that addresses most of the requirements that are mentioned.
Start from the idea of hooks most generalized. For each pattern that matches, we want to bind a number of type of things to it that relate to what we are calling hooks. Generalized, internally a pattern has a set of hooks that can be called by other patterns and may also have some parameters. The hooks will be stuff like
:layout, or render actions, :show, :edit, or for permissions :auth and related :edit, :read, :comment, etc. The idea of this DSL is just a way to bind these hooks. In the DSL you just say what is bound to a set of symbols (the hooks), what plus cards to look to for parameters (including virtual search cards) and how to map those parameters to a result, which depending on the hook might be a a fail/allow code for authorzation, or a view/type conditioned template for the rendering phase. The point is that we just add symbols to this DSL to add hooks to the application and you can use them however you want.
From email:
On 10/12/09 6:03 PM, Lewis Hoffman wrote:
>
>
> On Sat, Oct 10, 2009 at 5:47 AM, Gerry Gleason <gerryg@inbox.com
>
>
>
> A few quick clarifying questions:
>
> The patterns stuff is also a cardtype, right? I mean this stuff all
> hangs on the way pattern cards work. Some of this may be a bit
> circular
> as you want to define (using patterns) what plus cards on patterns
> have
> what functionality. Maybe this is part of some pattern stuff that is
> not in cards, but bootstrapped into the code, but if we can
> bootstrap it
> by loading some pattern related patters first ...
>
>
> It could be circular & thus require bootstrap, but I think it's not
> the way I have in mind to implement it.
> Basically there are two layers of patterns. First there is a pattern
> API which is independent of Cards, which lets you create pattern
> classes, and manage code or other settings in an internal store (ruby
> hash). Then module hooks, declarations/invocations etc. are built
> using this first layer of the pattern API. Then pattern cards are
> build using module hooks and the lower level pattern API. Pattern
> cards will also likely require an external store such as memcache for
> some indexing.
>
Every cycle thinking about this stuff, I may start to think I understand
some of it, but I think I am largely just confused. I've gotten
glimmers from your first explanation of what patterns would be and my
own thoughts on that, and then your explanation above and the pseudo
code examples. Right now I think I'm more confused than ever, but I
will attempt to write about what I see as possible now not knowing if
that is really what you are already saying.
At first I was thinking about a pattern as a named thing (the cardname)
that has some WQL or more generally search code that defines a subset of
the Deck that matches the WQL pattern. Now I understand that we now
have a card and all of its potential plus cards at our disposal, but how
do we combine them. I'm thinking now that we may only need one DSL for
pattern cards, and then even Search cards are just a subset of pattern
card functionality. From a security standpoint we may need to be able
to specify (with patterns) cardtypes that can use only part of the DSL
that is safe to give in terms of the potential to load malitious code
through pattern cards.
So, would it be sufficient to define pattern cards (and its 'subclasses'
as we define that) as the form of script that we program wagns in. I.e.
a critical part of Wadl. I'm thinking now that we may be able to create
a core where all of what Wagn is, vs. the general space of "card apps"
is a set of cards plus some gems to support the cardtypes and other
controllers that are pulled in by Wadl declarations (in the cards).
So the question is what would that language be and how does it work?
I'll just outline my thoughts here in the hope that it either matches
what Ethan and Lewis are already thinking and helps us explain it all,
or I have some insights that help enhance the design.
So in this DSL, I need to be able to express:
1.) The set or sets of cards that match this pattern. There may be a
set that is said to "match the card" in a default sense, and subsets
based on the pattern context. This will be search terms (WQL) or other
conditionals, and the subsets can be bound to symbols that can be used
in the DSL to refer to those subsets.
2.) Transclusion syntax within the DSL can be used so that the DSL can
refer to <pattern>+<tag> if the tag is a virtual card (and maybe a
virtual card is just another pattern/search card) I can then fetch a
plus card that returns a set of pointers to other cards. The DSL can
use these plus cards however it wants, the set of pointer might be the
set of roles that are allowed to do something like this:
auth :role -> :edit_ok, :roles -> # :roles could be
defaulted this way from :role
And now I can easily define permissions in terms of these auth roles. I
might need a little DSL glue to connect these roles to the sets of cards
they apply to, but I think this give an idea of what is possible with
this approach.
3.) Looking at the way layouts are integrated as cards now has me
thinking that if I first ask the pattern system for the "layout" for the
current card, or something like that. This layout can include a number
of other cards, but central to being a application for cards, the card
controller has to format the "main" context from the card action coming
from the application controller. The pattern DSL code for the layout
has to do everything that current layout cards/files have to do, but it
would also have to use the pattern system to expand the action on the
current card.
My question is whether we can completely define base Wagn functionality
this way. Then the card controller "is" the pattern controller more or
less. Rendering a card for an action is just something like this:
while (patterns('*layout').run) {}
the run method returns true (or some object maybe) whenever the running
of a pattern results in another pattern
Is it possible that if we define the DSL right, the card controller is
really this simple?
Gerry said: So in this DSL, I need to be able to express:
1.) The set or sets of cards that match this pattern. There may be a set that is said to "match the card" in a default sense, and subsets based on the pattern context. This will be search terms (WQL) or other conditionals, and the subsets can be bound to symbols that can be used in the DSL to refer to those subsets.
~~~~~~~~
The pattern card *is* wql that defines all the cards. I don't see adding another layer of defining a set of cards. in general, when we need to do a group of cards, I'm guessing it'll be Pointers (explicit lists), Searches (implicit lists), or some snifty interaction of the two.
--Ethan McCutchen.....Thu Oct 15 14:00:38 -0700 2009
2.) Transclusion syntax within the DSL can be used so that the DSL can refer to + if the tag is a virtual card (and maybe a virtual card is just another pattern/search card) I can then fetch a plus card that returns a set of pointers to other cards. The DSL can use these plus cards however it wants, the set of pointer might be the set of roles that are allowed to do something like this:
auth :role -> :edit_ok, :roles -> # :roles could be
defaulted this way from :role
And now I can easily define permissions in terms of these auth roles. I might need a little DSL glue to connect these roles to the sets of cards they apply to, but I think this give an idea of what is possible with this approach.
~~~~~~~~
Gerry, I think I need examples to be able to follow you. This seems to me more syntax-heavy but less powerful than what I described in Pattern Cards+permissions, no?
--Ethan McCutchen.....Thu Oct 15 14:03:22 -0700 2009
Sorry that I haven't created better examples. My point isn't actually about the specific syntax, yours is probably better, and we all need to contribute to that space. My point is that we can define the entire flow of processing, the VC parts of the Decks and Cards MVC in this DSL with modular support. In this flow, layout proceeds to view several support cards, pass the main action on to a card action renderer. If the naming of the components is done in a DSL, we give the kind of complete control over module composition that was desired in the discussion. The declaration of the permissions and auth stuff actually configures how that subsystem will work.
In my example, "auth" would also be the name of the pattern plus cards (i.e. +auth for each pattern matching the card) that is supplied to the block or blocks that decide if the user is authorized for an action. You would also have to say someplace in the DSL how to process the "edit" action and that would access "auth" declared patterns. This really isn't that different than the code flow is now, it just move a few critical pieces to cards because we want to configure them. I don't actually expect much performance impact from all of this refactoring.
--Gerry Gleason.....Fri Oct 16 03:41:12 -0700 2009
Is there anything in what you're suggesting that would alter how Wagneers interface with Pattern cards to accomplish the kinds of setting expressed in the needs section?
If not, then are you talking about solutions to an undefined problem? We need the "needs" expressed somewhere. The only solutions that belong on this particular Blueprint card are those that address +needs. Because most of what you're saying seems to address things that we might in the future, do you think this should be another Blueprint?
The things that would help me most are: (1) concise expressions of the needs you want to address (2) EXAMPLES of how it might look to interact with the structures you're proposing, and (3) some implementation time reference (eg. after introducing Modules, by the time we've introduced modules, etc).
I'm also wondering if you can either (a) use terms as we're defining them, or (b) let us know when you're proposing alternative definitions. As an example of what's making it hard for me to grok, you introduced this card saying:
"The important move is the treatment of the DSL as distinct from patterns, but important for their definition. Rather than try to attach these definitions as plus cards to patterns..."
This doesn't seem to be using the framing spelled out in all the other cards here. Pattern cards are a subset of Search cards. Nothing is "defined" in their plus cards -- the pattern is defined in the WQL. Settings are created in plus cards. So what do you mean by "definition" here? you continue:
"...we move them out to separate namespaces (proposed as System+Patterns+ , System+Type+ or System+Hook+ and so on)."
I thought we'd agreed that decks are namespaces. I like that, because they clearly are separate namespaces, while plus cards are not. If you change the tag you change the plus card -- the namespaces are bound, not separate. The closest things we have to separate reserved names within a given Deck are star cards and (to a degree) codenames.
Still, I would love it if you would continue and spell out that example. I have no idea what you where thinking of making "System+Patterns+ " mean. It has a name (sort of), but what's its type? its content?
--Ethan McCutchen.....Wed Oct 21 14:23:49 -0700 2009
I though we had a bit of good communication on this on the call. What I want to define here is the grammar for defining what the wagneer sees. With an eye towards 1) extending it to define new wagneer visible features, or 2) defining alternates for any of the main wagn components in the extended card app space.
What I see is that code in the core, methods or method/card w/DSL hybrid now define a baseline Wagn pattern that can be extended in a number of directions, and many but not all of those directions will be completely compatible with wagns.
For example, what if as a community member I wanted to put an SVG editor inside a card. The revisioned content is now svg (content-type wise), and I have custom javascript to manage what happens inside the cardframe in communication with the card controller for the cardtype in the slot.
What if I want to implement a wagn, but I want to translate all the keywords, actions, view modes and all that into another language? French or Spanish? I need a place to make those bindings that doesn't disturb the core of the application. What if I even want French words for "Cardtype" and "Basic", "Image" and the rest. Even inside WQL code and transclusion options all the words, left, right, self, etc. are translated?
--Gerry Gleason.....Mon Oct 26 10:29:38 -0700 2009