No problem, I can wait ;)
On the hierarchy thingy...
On my own projects I used to use routing for this.
Since rails 2.0, routes have become very clever and I use them for
breadcrumbs as well as for determining hierarchy-like stuff.
Automatic routes are great, but the thing you describe(that don't really
belong in the model, but aren't DRYML tags either) is what I would like to
call 'the application' as in 'navigation and structural behaviour'.
Thinking about it, especially using RESTful conventions, controllers have
'dumbed down', and they should only be concerned with object
handling(interface to models).
All-round application-look-and-feel shouldn't be handled by individual
controllers (since some controllers are multi-use, like a comments
controller in an application where you can comment on many different types
of things) but defined application-wide. This is stuff like navigation
(where to redirect after some action) and probably other stuff.
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.
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.
At the moment I let my applicationcontroller handle most of it (since it's
application-feel we are talking about here).
It handles stuff like parsing the url(the chosen route) to initialize
objects, parses hidden referer fields to use later when redirecting and for
setting up the breadcrumb(to simulate deeper nested routes).
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.
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.
So routing and nesting and scoping are high-priority for me and one of the
first things I'll get working on after getting to know hobo a little better
all-round.
It will 'fix' url-hanling too, as we discussed earlier on IRC.
For dryml (I mentioned above) I think a bit more css-like behaviour would
help to get 'overall-application' look&feel in shape.
I'm not good at dryml yet so maybe this is already possible or I might be
doing it the wrong way.
The other day I needed to adjust some labels in field-lists for some model
because the fields needed some explaination.
Maybe hobofields can be extended for this, but I tried using dryml to get
this done.
<field-list:>
<tags-label:>Tags (research)</tags-label:>
<fase-label:>Fase (promotion)</fase-label:>
</field-list:>
This was the bit that was needed, but since field-list isn't polymorphic, I
had to put it in many places.
I extended form for user, show-page for user and signup-form for user as
well, since it doesn't inherit from form-for-user.
I probably could have globally extended field-list, but that would have
affected other models as well if they happened to have had the same fields.
Anyway, what I mean by css-like is a bit like this (pseudo, invalid xml):
<* for="User">
< * >
<field-list>
<tags-label:>Tags (research)</tags-label:>
<fase-label:>Fase (promotion)</fase-label:>
</field-list>
< /* >
< /* >
Which means something like a field list below(any level) an element with
for="User" (or better yet, where the implicit context is set to a user)
should override some params.
No matter what page it's on.
Stuff like that can dry up dryml even further I think. It might get
complicated though, and finding a nice syntax won't be easy as well. But it
_is_ striking with pinpoint accuracy like the agility tutorial mentions.
Anyway,
I'm keeping you off from real work :)
Don't feel bad by not answering posts like this one soon.
It's just a lot of ideas that I get from using hobo and from matching hobo
to my current workflow.
Eventually they may help shaping hobo's longer-term future by exploring
overall application design patterns.
Mathijs
2008/9/6 Tom Locke <[EMAIL PROTECTED]>
>
> > it seems :dependent => :destroy is needed to have automatic
> > collections on a show page.
> > Not sure if this is logical?
>
> Yeah there's a story behind that.
>
> When we were trying to improve Hobo's automatic UI that it creates, we
> were looking at hand-crafted websites for patterns. One obvious one is
> that the models tend to be arranged in a hierarchy. The site contains
> projects, projects contain stories, stories contain tasks, etc...
>
> If you know what this hierarchy is, you can do cool things like
> breadcrumbs (or parent links at least - which Hobo now has), embedded
> collections and forms, etc.
>
> We didn't like the idea of declaring this hierarchy in the model, as
> it's really a view and maybe controller concern. What we did notice
> was that :dependent => :destroy can be used as a way to guess the
> hierarchy. When you delete the story, you delete the tasks.
>
> That's where that idea came from, but it's not really a very good
> idea : )
>
> A feature that's coming up is a new place to make declarations that
> don't really belong in the model, but aren't DRYML tags either. You'll
> be able to declare this hierarchy in there, and the page generators
> will use it to build a more sensible app.
>
> Tom
>
> (p.s. not sure when I'll get a chance to reply to all you other posts
> but I'll try to get to it asap as you're obviously forging ahead!)
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
