PS: I would say that after every auto tag def, there should be an html comment with the extend tag already written in its simplest form, for easy C&P. One could even edit it there within the comment while looking at the origional tag, and then copy it out.
On Nov 6, 11:47 am, Peter Ehrlich <[email protected]> wrote: > So I just wrote a giant post and it got eaten by google groups. > Hooray! Here we go again: > > 1) Tags. I would say that files for both auto generated and user made > tags should reside in a model folder with the pages themselves. When > I use the auto file, I search for the model name, and then scroll to > get the tag I wanted to look at. (This is not aided by having models > named (Item and ItemSupplier, e.g.). Benefits of splitting the single > file in to multiple: > - The nature of the auto-gen file lends itself to being split up - > the form repeats itself. Splitting it would mean shorter files, and > if you want to increase the amount of auto generated code per model, > it doesn't have a multiplicative effect. > - Succeeding the the auto-gen file, have the tag extension .dryml > file. Ironically, all your code is now in one place - a folder. > Working on one resouce? Just open the folder. New to hobo, confused, > and debugging your resource? Just look in the folder. I myself have > forgotten both viewpoints and application.dryml (when starting out) > causing embarrassingly long setbacks. K.O. this learning curve! > - I don't see this as any less flexible -- it is (if we reach > consensus) simply establishing a convention that will help people. It > seems in line with both hobo and rails patterns. And if it is somehow > less flexible, I don't see that as such a bad thing: flexibility is > important either when you don't know what you want (in which case, a > good convention is good) or you have a really weird app (in which case > this won't be the only convention you're rubbing up against, and > something is probably very wrong.) > > 2) Viewhints: How are they more model related than any other view > code? Take a look at app-name and set-theme in application.dryml, > which are similar 'sort of general directives'. Viewhints should be > tags, just like all the other display-related code. Example: > > <extend tag="meta" for="Pancake"> > <model-name:>Flapjack</model-name> > <field-name:number>Favorite Number</field-name> > <field-name:name class="conjecture">Fancy <a > class="bubble_help">Name</a></field-name> > <children: fields="toppings"/> > </extend> > > Such code would fit perfectly in to the top of 'views/pancake/ > _user_tags.dryml'. The default ones would fit in to 'views/pancake/ > _auto_tags.dryml' and both together would provide a fantastic > introduction to the workings of hobo. > > @dd, Owen -- Hopefully this isn't coming across as too aggressive! As > a newbie this looks like a good idea and it'd be cool to see where it > goes. > > Cheers! > --Peter > > On Nov 6, 8:56 am, Owen Dall <[email protected]> wrote: > > > > > > > > > Keep the feedback coming! > > > -Owen > > > On Sat, Nov 6, 2010 at 8:44 AM, Domizio Demichelis > > <[email protected]>wrote: > > > > Peter, > > > thank you for your feedbak. > > > > 1) Each model folder would hav a .dryml for the tags as well. Similar > > >> to application_helper.rb, have a application_tags.dryml in the views > > >> root folder. This begins to separate code for different models. > > > > If you mean to split the auto generated taglibs (the > > > app/views/taglibs/auto/rapid/pages.dryml) into separated files, I think it > > > would complicate things, because you will have to search the right file > > > when > > > you want to copy some tag in order to extend it. IMHO the all in one file > > > structure is perfect, for its use (i.e. open it to copy some tag). > > > > If you mean the tagibs that YOU add, actually the current structure is > > > more > > > flexible that what you are proposing, since it allows your structure, but > > > also allow ANY other structure that might be more appropriate in other > > > contexts or developing styles. > > > > 2) Viewhints. Replace these with special tags in the model-specific > > >> tag files. They effect a page layout similar to how a view does, and > > >> this helps keep all relevant code in one place. This also keeps to > > >> the tags convention and is therefore well-expandable in the future. > > > > The viewhints are model related hints for displaying data into pages: sort > > > of general directives, so it seems quite appropriate to express them in a > > > ruby file, anyway, could you plase give us some practical example to do > > > the > > > same in dryml? > > > > Hopefully this would be more intuitive and easy to use. Other cleanup > > >> could be done, such as moving automatic tags to their on files within > > >> model view directories. To keep things neat, prefiex underscores > > >> could be used, which might be nicer than a folder. > > > > For example? > > > > ciao > > > > dd > > > > -- > > > 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]<hobousers%2bunsubscr...@googlegroups > > > .com> > > > . > > > For more options, visit this group at > > >http://groups.google.com/group/hobousers?hl=en. > > > -- > > Thanks, > > > Owen > > > Owen Dall, Chief Systems Architect > > Barquin Internationalwww.barquin.com > > Cell: 410-991-0811 -- 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.
