2008/9/12 Tom Locke <[EMAIL PROTECTED]>
>
> > Hobo tackled the visual part of application-behaviour with dryml and
> > polymorphic tags (not fully, but it's a good step - more below).
> > The navigation and 'context' part(including breadcrumbs) belongs
> > still has to be tackled.
> > I think routing is a very good place for this, since it perfectly
> > maps what is available where.
>
> I disagree. Say I have projects and stories, like in Agility, and say
> I want the user to experience the site as a hierarchy of projects that
> contain stories. That doesn't mean I want stories to live at
>
> /projects/123/stories/456
>
> I want it to be simply
>
> /stories/456
True, but that doesn't mean /projects/123/stories or
/projects/123/stories/456 shouldn't be available...
>
>
> For example, suppose the story moves to a different project, why break
> it's URL?
Well, /stories/456 should still be available.
/projects//123/stories/456 can display some message saying the story isn't
available on that project anymore and offer a link to /stories/456 or to
/projects/246/stories/456 if some preference says stories should be scoped
through projects. Kind of like the way hobo determines the 'parent' now.
>
> > Since deeply nested routes(more than 2/3 levels) are bad and
> > unneeded, I use a combination of routing and session (or hidden
> > referer in forms) to keep things making sense navigation-wise.
>
> I did this once in an app -- used the session to keep track of certain
> navigation issues. Never again :o) I realised that it's really
> breaking the principle of the web that resources should be properly
> identified by the URL alone. You're probably not talking about the
> same kind of mistake that I made, but I'm still very much against
> using the session for anything more than absolutely necessary.
The session is a disaster for these cases, that's for sure, especially if
people use many tabs/windows.
I changed to using special hidden fields on forms, and (ab)using the referer
header.
>
>
> > I think that some nice DSL would be best to define these rules.
> > Like I said, automatic routes are great and should stay, but I think
> > a DSL to hint/adjust them a bit would be awesome.
>
> Agreed. I've been wanting to add that for ages.
>
>
> > At the moment, I really miss stuff like /projects/3/stories (as get
> > request) for scoping data.
> > (ab)using the 'parent model' show page is a nice alternative for
> > html, but not for xml/json stuff.
>
> Can you explain a bit more? What would you want at a URL like that
> that Hobo doesn't already provide?
All stories on a project.
Say I want the project-page clean, since a project has many data to display
already (project owner, company/customer info, some history, billing info,
stuff like that) In that case I might only want to show a small summary of
'child' objects (stories), maybe the latest 3, or the most active/popular
ones. Especially if there are many 'child' possibilities (like a project
that has stories, and invoices and releases, attachments and more),
cluttering up the 'parent' (project) show page is not an option. Also when
data has to be available as xml/json (or an rss feed), this is useful. If I
want an rss feed for all stories on a project, it has to be
/projects/x/stories.rss since I don't want items for invoices, but the
people at finance do. Of course a general /projects/x.rss feed should
combine those.
>
> > <* for="User">
> > < * >
> > <field-list>
> > <tags-label:>Tags (research)</tags-label:>
> > <fase-label:>Fase (promotion)</fase-label:>
> > </field-list>
> > < /* >
> > < /* >
>
> We have talked about the idea of replacing polymorphic tags with tags
> that are chosen according to their nesting in CSS classes. This would
> be very powerful, for example allowing you to define "card for user in
> the sidebar" differently from "card for user in the main column".
> Something like
>
> <def tag="card" select=".aside .user">...</def>
>
> But this is definitely "next generation" DRYML, and won't make it into
> Hobo 1.0
That's the stuff I mean, it's very cool, but I don't need it just yet :)
What I would like (maybe it's there, but I just can't find it) is inheriting
polymorphism (buzzword alert).
If I want field lists on users to always use some different labels, no
matter on what page or form they are on, I would like to be able to say:
<extend tag="field-list" for="User">
<old-field-list merge>
<username-label:>Name on this site</username-label:>
</old-field-list>
</extend>
but I can't use for on field-list.
It would be cool if it detects that one of its parent-tags (show-page, or
form) has for="User", so this applies now.
For now I have to resort to extending form for user, and different pages.
<extend tag="form" for="User">
<old-form merge>
<field-list:>
<username-label:>Your name on this site</username-label:>
</field-list:>
</old-form>
</extend>
extending form for="User" works on the user's edit-page, but doesn't help
for the signup-form though, although signup-form uses the form tag, the
extension isn't applied.
So I have to become undry again to fix this.
Also, I'd like the ability to add/remove stuff from list-like
attributes(like fields).
It would be nice to put fields="+age" or fields="-username" in extend's.
Or something more cryptic like fields="&(original_attribute.split(', ') -
['username']).join(', ')"
To me, rapid is cool, but when you start changing your views, you loose many
of its automatic-generation aspects.
Maybe it's just be doing things the wrong way though :)
>
> Keep all this good stuff coming!
I'm sure I will :P
>
>
> Tom
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en
-~----------~----~----~----~------~----~------~--~---
