+Theme
Architecture of the Future

+Date
February 15, 2012

+Blurb
Refactored to use Rails 3 and other current tools, 1.8 prepares Wagn for long-term viability.

 

Wagn 1.0 was a pioneering web app.  Wagn 2.0 will be a pioneering web app and web platform.

 

The current release (Wagn 1.8) gets us considerably closer.  To name a few highlights:

  1. uses Rails 3 - the latest and greatest.
  2. supports Ruby 1.9 (1.8.7 still works)
  3. new file and image handling is more secure, flexible, and re-usable
  4. new settings editor is much crisper and easier to understand
  5. Almost 50 tickets resolved: new features, bug fixes, performance enhancements, etc.

This release includes more resolved tickets and more commits than any prior Wagn release, and yet the codebase is actually smaller than ever.

 

 

+tickets by status

open

in progress

coded

testing

closed

 

 

Migrations:

 

http://en.dwagn.org/wagn/*when_created+*right+*content

http://en.dwagn.org/wagn/*when_last_edited+*right+*content

 

http://en.dwagn.org/wagn/email_config+*right+*edit_help

http://en.dwagn.org/wagn/*account

http://en.dwagn.org/wagn/*account+*right+*content  ("item": "change")

 

Added "sort" to WQL:

 

http://en.dwagn.org/wagn/*attach+*right+*options

http://en.dwagn.org/wagn/*editing+*right+*content

http://en.dwagn.org/wagn/*editors+*right+*content

http://en.dwagn.org/wagn/*includers+*right+*content

http://en.dwagn.org/wagn/*inclusions+*right+*content

http://en.dwagn.org/wagn/*links+*right+*content

http://en.dwagn.org/wagn/*linkers+*right+*content

http://en.dwagn.org/wagn/*plus_cards+*right+*content

http://en.dwagn.org/wagn/*plus_parts+*right+*content

http://en.dwagn.org/wagn/*refers_to+*right+*content

http://en.dwagn.org/wagn/*referred_to_by+*right+*content

http://en.dwagn.org/wagn/*roles+*right+*content

http://en.dwagn.org/wagn/*watching+*right+*content

 

Changed to offer radio buttons of the options:

http://en.dwagn.org/wagn/*input+*right+*default

√ http://en.dwagn.org/wagn/*input+*right+*options

√ http://en.dwagn.org/wagn/*input+*right+*input

√ http://en.dwagn.org/wagn/*input+*right+*edit_help

 

√ css references in *tinymce

√ local image references in *css

 

√ drop superfluous indexes on cards table.

√ drop unused tables: permissions, card_files, card_images, system, open_id stuff, db_files

 

√ edited to editor in WQL

 

TODO

√ new Layout cardtype.

file/images

 

 


 

These we want to do after we handle card parts when creating previously virtual cards (status:

):

http://en.dwagn.org/wagn/*attach+*right

http://en.dwagn.org/wagn/*bcc+*right

http://en.dwagn.org/wagn/*cc+*right

http://en.dwagn.org/wagn/*from+*right

http://en.dwagn.org/wagn/*to+*right

 

I looked at several sites and couldn't find any issues with these cards.  I can believe there might be rules out there missing sets, or, more generally, plus cards missing parts.  If we find any of those, my inclination would be to try to build a smarter migration that's smart about the pattern and finds all the busted data it can.  -efm

 

 



 

TODO: ticket the following (and move over comments until double horizontal rule)

migrate old sites to hard-templated cardtypes

 

http://en.dwagn.org/wagn/Cardtype+*type+*content

http://en.dwagn.org/wagn/Account_Request+*self+*content

http://en.dwagn.org/wagn/Set+*self+*content

http://en.dwagn.org/wagn/Setting+*self+*content

 


 

We can't migrate Cardtype+*type+*content, because it will override all kinds of custom Cardtype cards. Eg, on wagn.org alone (which is not our biggest problem), it would break Ticket, Deck, Support Ticket and probably several others.


We could check each |cardtype| card, and if anyone beside WagnBot has edited it, add a |cardtype|+*self+*default card.

  --John Abbe.....Sun Mar 20 19:08:29 -0700 2011

 



So...most of the tickets in testing now can only be tested on the new server?

  --John Abbe.....Sun Dec 18 22:18:15 -0800 2011

 

Yes.  Would it be helpful if I made so that you could still somehow access the old site?  --efm


So far I've just been testing whatever seemed most interesting/fun/easiest to me. If you want to let me know what you think is most critical, or most in need of testing, I can throw your criteria into the mix as well...

 

hmm.  good question.  I guess if there are ones that look easy to close it would help improve the signal to noise ratio...

  --John Abbe.....Fri Dec 23 23:58:41 -0800 2011


What new Layout cardtype? (not seeing it on test or play)

  --John Abbe.....Mon Jan 02 15:56:01 -0800 2012

 

It's not there to migrate yet, but I need to create a new Layout cardtype for handling _main.  Discussed briefly in add reference syntax for main card of page -efm



Just ran all the migrations on test, play, and cp staging.

  --Ethan McCutchen.....Tue Jan 03 20:47:58 -0800 2012


guess we should prioritize the "_main" testing...

  --Ethan McCutchen.....Wed Jan 04 10:40:26 -0800 2012


Documentation to update:

_main in links, inclusions - contextual names, sidebar, custom layout

views: new and edit (and editor), and (for code only) open_rule, closed_rule

CQL Syntax - _main, sorting by plus cards

.file - new file format for downloading

  --John Abbe