So, sort of a supernaked view, like naked but without any enclosing HTML? --John
that's what naked is, actually. Current issue is with layout, where even "none" creates a "main" div.
also want to optimize this for speed and make clean url
--Ethan McCutchen.....Thu Nov 18 15:54:10 -0800 2010
Looks like http://test.dwagn.org/*css?view=naked&layout=none works as wanted now - so are alterations to "none" in testing?
--John Abbe.....Sat Dec 25 10:46:27 -0800 2010
You know, now I'm having trouble seeing that issue even on the live server. And I see the code that fixes it -- it's not new. So evidently I'm confused.
Still want cleaner url...
--Ethan McCutchen.....Mon Jan 10 17:05:29 -0800 2011
I'm not seeing any HTML either, in http://test.dwagn.org/*css?view=naked&layout=none or http://www.wagn.org/*css?view=naked&layout=none (except code and /code on the latter)
You mean a cleaner url than http://test.dwagn.org/*css?view=naked&layout=none ?
--John Abbe.....Mon Jan 10 19:35:01 -0800 2011
yes, this is a very common case and needs a simple url. something like /*css.txt or /txt/*css
--Ethan McCutchen.....Tue Jan 11 09:03:44 -0800 2011
This opens up some big issues to me. I'd like to remove wagn from canonical URLs and generally move URLs like /card/edit and /new/|cardtype| in the direction of being Wagneerable. I'm also in favor of allowing card names with endings like .html and .txt, so one way I think of going is the latter URL, if "txt" is a card of a new type, say, Folder. A new setting (*folder) could allow placing any card in one or more Folders, so if "*css+*folder" Pointed to the Folder card "txt", then a URL using /txt/*css would return the content of *css (raw & naked view by default?). Folder cards could also be used to provide a Wagneerable interface to things like the "special" folder being used on the Pattern Language of Group Process Wagn (where there is an actual external file). Obviously this isn't fully thought out yet, but it's where I start to go...
If you want a quick and dirty solution, I'd prefer /txt/*css because I really want to be able to name cards with file endings and have them treated normally. My primary use case for this is switching an existing site with .html files over to Wagn without breaking links.
--John Abbe.....Sat Jan 15 18:04:22 -0800 2011
It's worth nothing that we already have several files endings: html|json|xml|rss|kml. The html ending will not be a problem, since that's the default format we use, anyway. If you import "dogfood.html", then the natural cardname is "dogfood", not "dogfood.html", though the url would still work.
I don't yet see this as a use case worth giving much weight. For one thing, it's all theory right now -- nobody's actually having this problem, as far as we know. But more importantly, the natural solution would be to redirect the urls in a patterned way, not to leave people stuck with awkwardly named cards. That way we could handle all sorts of nested directories and other common patterns that aren't as simple as x.html.
I'm definitely on board with using this as an opening into removing wagn from canonical urls.
I re-read your comments on *folder three times and am not sure I'm grokking it. Is it mostly about having the same card addressable with multiple different urls but having the url prefix configure different default display settings? It's definitely interesting to think of ways to get beyond our current situation, where a given card's setting patterns can only be overridden by inclusions.
The format endings address a slightly different need, in that they will generally involve file formats and therefore actual code. I do see why you want to leave that in the namespace, but it's going to be hard to get around the fact that the endings will be a huge boon for interoperability. For example, if you can just add ".pdf" and have wagn return a pdf version of your card, then browsers will know how to handle it, and other programs could potentially integrate very smoothly with a url.
I don't see the connection of *folder to the special folder, the point of which is largely to get around card limitations. I would think the way of making that kind of thing wagneerable is to make cards more powerful, not to extend wagn into providing interface into lower-level server functionality.
--Ethan McCutchen.....Sat Jan 15 18:40:48 -0800 2011
Hmmm, I don't much like the idea of extensions like .html being part of a cardname because the routes parsers expect that to go to :format. If you want to represent file types in Wagn, I recommend using + in place of . or maybe +*, then *html+*right can define it.
Or am I missing something?
--Gerry Gleason.....Sun Jan 16 06:36:13 -0800 2011
I think the real solution here is 1) Implement the idea that defined cardtypes inherit from the *default setting's cardtype, and 2) A basic cardtype that implements the formatting you want.
I played around with adding cardtypes for this kind of formatting, but in needs to be generalized with doing 1) so people can add new cardtypes that get this plain formatting (or any other for that matter)
--Gerry Gleason.....Sun Jan 16 06:41:47 -0800 2011
BTW, this is probably only a couple of lines of code to change. The testing and migration implications are the bigger problem because they are somewhat unknown.
--Gerry Gleason.....Sun Jan 16 06:43:30 -0800 2011
Gerry, when you say "the real solution here is".... what problem are you solving? Doesn't seem to address multiple display profiles for a single card. John's idea is one way to address that. Another would be via virtual cards that do little but redisplay (with a new profile). I think that's valuable for other reasons but don't see the relevance here.
As for the extensions being part of the cardname, I agree. I don't like it much either. John, we he's talking about the "routes parsers", he's talking about some built-in rails stuff that makes it far more natural to use those endings as extensions, not as part of the card name.
I do think, john, that we can address your naming concerns without putting the extension in the cardname. And by keeping it out, we stay much truer to the idea that a card can be presented in many formats -- and is not ultimately tied to one. I don't know that we've ever really spelled that out as a design principle, but it seems important to me.
--Ethan McCutchen.....Mon Jan 17 11:06:48 -0800 2011
I thought the issue here is how the content is displayed, but maybe I don't understand. My point is that the "formatting" for a card is ultimately controlled by the Card class for the card in question.
I was thinking this was like the hack I did for displaying XML cards with colorizing, and at the same time I was playing with a "Css" cardtype which made it a "plain text file". What I didn't like is that you have to add base cardtypes to do this, but if we implemented the idea I suggest, you could create any number of new types whose real type is a "plain text" type and renders correctly for that type.
Or is this about something else?
--Gerry Gleason.....Mon Jan 17 11:50:20 -0800 2011
Well, I think the main thread of the conversation is about having multiple ways to view the same content more than about changing the anything about the card's content itself. You're definitely right to say that the .format stuff brings us into that territory. But what we really need to work out here is more about wrapping the content than rendering the content, and I think your point about inheritance speaks more to the latter, no?
Not that that isn't a great inquiry, because sometimes the format will involve serious rendering questions. In the case of a css card, though, there's not that much to it -- at least until we get into syntax highlighting and such. another great inquiry, but still not really the one at hand ;)
With the example of *css, there are two different ways we need to be able to interact with it: (1) as a normal card that we edit in some context on the site, and (2) as a .css file that gets used by a page. The former needs to be nested within a normal layout and have all the normal slot info. The latter needs to be layout-less and naked.
The current solution is to solve (1) with /wagn/*css and (2) with /wagn/*css?layout=none&view=naked. My point is that we probably want some shortcuts to that.
One way to do that would be to make some special routes, like /txt/*css that involve special layout and view parameters. That could certainly work.
But my question is whether some of that shouldn't be implicit by the format. If you go to cardname.css or cardname.txt, will you ever want a layout and card slot? Shouldn't it be implicit that you want that stuff with cardname.html (or just cardname) and not with cardname.css?
--Ethan McCutchen.....Mon Jan 17 13:09:15 -0800 2011
Ahh, now that I understand the issue. Isn't what you want "Html with no layout", and maybe "naked" too. I think asking for a card with .css "format" should just give you that? Maybe that is what you are saying at the end here.
No, I don't think you ever want a slot, etc. with *.txt or *.css. *.html means that explicitly.
--Gerry Gleason.....Tue Jan 18 10:09:33 -0800 2011
Gerry, yup, I think you and I are agreeing on this. Much of this thread is an attempt to persuade John. John, how are we doing? :)
--Ethan McCutchen.....Tue Jan 18 10:29:54 -0800 2011
I can even see doing this with *.html. Without any extension would still do all the default stuff with slot and layout, but with .html you could have render differently.
Are you thinking that these are controlled with settings and if so, what settings on what cards?
--Gerry Gleason.....Tue Jan 18 11:35:04 -0800 2011
I've been assuming .html would be the normal (in part because it allays some of John's concerns about imports), but would be open to discussing.
I hadn't thought about it being controlled by settings before this discussion, but John's *folder idea is clearly related. This kind of seems more like a module developer concern than a wagneer concern to me, but there may be some important opportunities I'm overlooking.
--Ethan McCutchen.....Tue Jan 18 12:06:13 -0800 2011
No reason you can't make it normal, but my point was the .html could be a different view/layout, but it doesn't have to be.
--Gerry Gleason.....Tue Jan 18 13:43:20 -0800 2011
"nobody's actually having this problem" - actually, this is one of the last hurdles to me shifting my entire site over to Wagn.
I think I'm convinced. If I'm understanding the file-ending proposal, an existing page ourpla.net/foo.html which I wanted to leave completely untouched could have its html copied to card "foo" and its custom layout made an empty HTML card. Then ourpla.net/foo and ourpla.net/foo.html would both return its HTML. Right?
I've started summarizing the solution as far as I'm getting it. Does this mean we disallow file endings in card names?
"we already have several files endings: html|json|xml|rss|kml" - you mean we do something special already appending these to card names? http://www.wagn.org/wagn/simple_url_for_text_pages_like_css.xml etc. return App error - ActionView::MissingTemplate: Missing template card/show.erb in view path app/views:vendor/plugins/exception_notification/lib/../views
--John Abbe.....Wed Jan 19 14:03:40 -0800 2011
The other hurdle is having Wagn pass requests of URLs to things it can't currently implement back to the web server. I've proposed a new set of solutions to allow access to other files and CGIs on the server and suggest we continue that conversation there...
--John Abbe.....Wed Jan 19 14:10:47 -0800 2011 (modified a bit later)
The idea is that you would copy the content of foo.html into "foo", and that foo.html and foo would be the same thing. HTML is the default file format. foo.html is the explicit version; foo is implicit. there's no need for a custom layout.
A slight variant on this design would actually allow the canonical name to be foo.html but store the key as just "foo". The effect would be similar. except that it seems like an annoying canonical name to me.
Yes, we would need to start disallowing file endings in card names. Wagn should be smart about it, though. If you try to create a card called "blah.html", it should tell you "wagn doesn't allow file endings on names; shall we just call it 'blah'?"
Re the current endings, it does special stuff that's actually in use with rss and kml (the google map files). I don't know if json and xml actually do much now or whether they're mostly place holders (though at one point Gerry was working extensively on this). html is not fully working, clearly, but it's close: http://www.wagn.org/Ethan_McCutchen.html.
I don't know what you mean by a CGI. You mean a script? We already have script cards...
I still say if you're interested in translating old urls in some non-wagny format into a wagny one, the answer is to build a translation layer, not to shape wagn's api around directly emulating every extant api out there.
--Ethan McCutchen.....Wed Jan 19 14:45:35 -0800 2011
For myself I'm okay with .html not being canonical. Others may want it, but we can cross that bridge when we come to it. Maybe a +*ending setting...
I coped and replied to the last bit on allow access to other files and CGIs on the server
--John Abbe.....Wed Jan 19 15:05:49 -0800 2011
TinyMCE offers code in the format dropdown. I added it to *tinyMCE but it doesn't work yet. My first thought was that we need to explicitly allow the code tag, but there's tons of other tags that are allowed at least before save. Relevant docs:
http://tinymce.moxiecode.com/wiki.php/Configuration:theme_advanced_blockformats
http://tinymce.moxiecode.com/wiki.php/Configuration:formats
http://tinymce.moxiecode.com/wiki.php/Configuration
Assuming we get it working I think having it in the menu is fine. As for buttons, there's a "code" button that we're already using, but that pops up the HTML window. Someone started coding a plugin to make a button for code tags a few months ago, this forum entry makes it looks incomplete, but we could contact them to see where things are now: http://tinymce.moxiecode.com/forum/viewtopic.php?id=23566
--John Abbe.....Fri Jan 21 12:34:16 -0800 2011
Researching a bit, I see that code semantically indicates that what's inside is code, and does not respect line endings or white spaces. I'm thinking what we really want is pre, which conveniently works, though I can't say I like the styling on it. I've added it as well, so you can try it out on any Basic card and see what you think.
Some people have had issues with the pre tag in TinyMCE (e.g. enter/return creating br's in FFox.), so someone coded a fix (I got there via this blog entry).
--John Abbe.....Fri Jan 21 13:33:20 -0800 2011
I partly updated Installation to pre's just to see what it looks like. I do like strong, maybe we could just use CSS to style pre strong by default?
--John Abbe.....Fri Jan 21 13:54:45 -0800 2011
I think on installation it actually is code (at least command line code), no?
Looks to me like code and pre are both allowed server side.
btw, I don't think we should add this on english; it will be noise for more users than it will serve. We should just write up clear instructions for how to do it on wagn.org somewhere.
--Ethan McCutchen.....Fri Jan 21 16:45:12 -0800 2011
Okay, I've updated Wagn 1.05+2+upgrade notes and TinyMCE. Shall I ticket make "code" work in TinyMCE's theme_advanced_blockformats?
--John Abbe.....Fri Jan 21 16:58:51 -0800 2011
Removed code from *tinyMCE - besides not working, five options give the menu a scroll bar, ugh.
--John Abbe.....Fri Jan 21 17:12:39 -0800 2011
Here are the things I now believe are working on dwagn:
- adding .html to a card name leads to normal rendering (text/html)
- adding .txt to a card name renders raw view (text/plain)
- adding .css to a card name renders naked view (text/css)
- the *css is now pulled in as a separate call (browsers should be able to cache it -- but I need to check on that)
One concern I now have is with permissions on *css. If it's not visible to "anyone", it will break when people aren't signed in. Of course, I could override that by rendering it as Wagn bot or something, but doing so would be a security risk, because you could then stick in all the inclusions you want and see any card on the site.
I guess we should just say, hey, if people can't see your css, they can't see your css. But we should migrate them all to be readable so we don't break sites on the upgrade.
--Ethan McCutchen.....Fri Jan 21 17:15:30 -0800 2011
actually, deploying now :)
--Ethan McCutchen.....Fri Jan 21 17:16:04 -0800 2011
makes sense (re permissions), and i noted it on the upgrade notes.
--John Abbe.....Fri Jan 21 18:16:48 -0800 2011
Tangentially, I've renamed and updated tweak CSS for pre.
--John Abbe.....Fri Jan 21 18:17:27 -0800 2011
http://www.dwagn.org/wagn/*css.html
http://www.dwagn.org/wagn/*css.txt and
http://www.dwagn.org/wagn/*css.css
...all seem fine, so I'd say we're done with part 1 except for verifying that browsers can cache *css.
Adding add file endings generating more file formats.
--John Abbe.....Fri Jan 21 18:35:40 -0800 2011
http://en.dwagn.org/*css says:
.card-header {
background: #C0D9C0;
}...but it's rendering with wagn.org's card header background color.
Sandbox is also affected, see http://sandbox.dwagn.org/ (vs. http://sandbox.wagn.org/ ). Oddly, in that case .card-header is being respected, but #menu is not.
--John Abbe.....Jan 20 from CSS on dwagn not being respected
working on it. problem is that the / * stuff is getting rendered. This content wasn't getting run through that part of the rendering process before, I suppose.
One solution would be to get rid of that syntax. That would obviously break some things, but if we don't like it, maybe sooner is better than later for that?
Most important page I know of that uses it is installation.
Other solution is not running built-ins through renderer. that might be worthy, too.
--Ethan McCutchen.....Thu Jan 20 12:40:32 -0800 2011
What part of the process does that? (you are talking about / * xxxx * / translating to <code>
xxxx </code>, right?)--Gerry Gleason.....Thu Jan 20 14:00:44 -0800 2011
it's Pre < AbstractLiteral in literal.rb. I've committed a fix that gets rid of it to the develop branch, but I'm not sure we want that in the release. I do know we want to move the css stuff into stylesheet link tags (I need that for a client), and that would also solve the problem. Working on that now. Oddly harder than I thought it would be.
--Ethan McCutchen.....Thu Jan 20 14:11:54 -0800 2011
awesome gardening.
re css on en.dwagn: it looks right to me. .card-header doesn't impact the top menu, just the headers of the cards themselves. are those dark green for you?
and the sandboxes look identical to me. screenshot?
--Ethan McCutchen.....Sun Jan 23 11:36:32 -0800 2011
all good now, the latest updates must have fixed it.
--John Abbe.....Sun Jan 23 12:22:30 -0800 2011
I've split what was 3. in the solution to a new ticket - disallow card names with handled file endings. So all that's left is the verification, and to remove the slash-star interpretation. (or "not running built-ins through renderer"?)
--John Abbe.....Sun Jan 23 12:26:25 -0800 2011
Vaguely recall we wanted inclusions to still render in .css, is that right?
--John Abbe.....Sun Jan 23 12:27:47 -0800 2011
Hmm, I think if something's being rendered as an inclusion, it won't have its own mime type. It will just come as part of the including file/response
--Ethan McCutchen.....Mon Jan 24 08:53:23 -0800 2011
Make .htm work the same as .html
--John Abbe.....Mon Jan 24 14:55:57 -0800 2011
#2 above is done. My leaning would be to gather and clarify a next round of specs for file type improvements (like the .htm idea, which I agree with) and work on them a little later on. This is in part because I want to dig in and understand some of rails' side effects before I add much more to the current setup.
--Ethan McCutchen.....Tue Jan 25 09:53:24 -0800 2011
Cool. I'll test when this is "testing". Did you verify what you wanted to about #1?
Already added add file endings generating more file formats.
.htm seems clear enough to me to go ahead with, but I can move it over if you like.
--John Abbe.....Tue Jan 25 10:03:17 -0800 2011
tests fine. not sure how to test if browsers can cache CSS, as described in +solution. Otherwise ready to close.
--John Abbe.....Tue Jan 25 14:50:09 -0800 2011
yep, I think 1 is done to my satisfaction for now.
I really need to work on the cache settings, though that's about server configuration, not wagn code. It looks to me like pretty much none of our js and css is getting cached, which is kinda ridiculous.
Let's ticket: optimize caching controls on wagn servers
--Ethan McCutchen.....Tue Jan 25 17:18:10 -0800 2011