Support Ticket

varying behavior of virtual star cards+status
varying behavior of virtual star cards+tag
 

*email - http://www.wagn.org/wagn/*email

*now - http://www.wagn.org/wagn/*now

*recent changes - http://www.wagn.org/wagn/*recent_changes

Search Results - http://www.wagn.org/wagn/*search

 

Thursday, April 25, 2024 02:55 PM CEST

 

 

 

 

They're all kind of different.  Which is your point.  But I mean conceptually.  The following is just to spell out the domain (not to suggest a route forward).

 

There are, in the language of the codebase, two kinds of virtual cards: "builtin" and "patterned".

 

Builtin

 

Among builtins there are also two types: searches and.. uh... other.  Here are the others:

  • *head
  • *alert
  • *foot
  • *navbox
  • *version
  • *account_link
  • *now

The above are all initialized at startup time and are coded in their own partials.

 

Then there are three searches:

 

  • *recent_changes
  • *search
  • *broken_link
the *search is broken above because there is no keyword being substituted.  It should be pretty easy to code a fix to avoid the error.  I don't really think there's much justification for having *broken_link built in.  (not sure there's need for any of them to be, frankly)

Patterned

 

The other kind of virtual card is "patterned", almost all of which are made by combining other cards.  The one exception is *email, which is essentially used in this case as a metadata accessor.  (administrators only)

 


So *broken_link shows cards with links to cards that don't yet exist?

  --John Abbe.....Tue Jan 11 16:12:17 -0800 2011


"initialized at startup time and are coded in their own partials." - what does that mean?

  --John Abbe.....Tue Jan 11 16:15:56 -0800 2011


coded in their own partials means they have separate rails view files for each card. initialized at startup means that wagn creates these cards an puts them in memory when it starts up (though their content is regenerated when they're rendered)

  --Ethan McCutchen.....Mon Jan 17 10:05:28 -0800 2011


My leaning would be to make it so that there are real cards (as in, represented in the db) for any "name part" in use. In other words, the only cards that are actually virtual would be those that are created by combining real cards. It would be highly impractical to represent all of those in the db. But everything listed above as "builtin" should probably have an associated card in the database. The builtin cards then become just another form of a card extension, but they only extend the x+*self set.

  --Ethan McCutchen.....Mon Jan 17 10:09:32 -0800 2011


Not understanding the last sentence, but adding make currently virtual star cards real.

  --John Abbe.....Thu Jan 20 00:55:00 -0800 2011


Also updated Star Cards to reflect this info.

  --John Abbe.....Thu Jan 20 00:55:52 -0800 2011


John, this is related to the last Wagn call. The "set based view declarations", which will include being able to declare one or more views on *now+*self, for example. It isn't really that different than current built-in initialization, but it is much more general.

 

Before, the code would say: Card.new("*now", :builtin=>true ...) and it would run code in:

cat app/views/builtin/_now.rhtml

<%= Time.now.strftime('%A, %B %d, %Y %I:%M %p %Z') %>

 

In the new design, this would be:

view(:raw, '*now+*self') do

Time.now.strftime('%A, %B %d, %Y %I:%M %p %Z')

end

  --Gerry Gleason.....Mon Jan 31 09:44:18 -0800 2011