Thanks again! I've been able to get the field name just fine with this_field.
Getting table name has been more challenging. The doc indicates that this_parent refers to the previous context, but I can't find anything about table names. If I cast it to string, I get the "name" of the record, as defined in my model. Without a cast, I get the error: Conversion failed when converting the nvarchar value 'Folder' to data type int.: SELECT * FROM [Translation] WHERE ([Translation].[TableName] = 9 AND [Translation].[FieldName] = 'MailCode') Interestingly, it does seem to find "Folder" (the table name) in there somewhere, but trys to cast it to int, and returns 9 (the record's ID). Any chance of a tiny bit more help here? Thanks so much! Steve. -- Steve Van Bruwaene International Teams Canada Special Projects [email protected] http://www.vanbruwaene.ca "Developing Resources that help IT Canada be More Effective in its Mission." IT Canada: 519-669-8844, 1 Union St., Elmira, ON, N3B 3J9 IT US: 847-429-0900, 411 West River Road, Elgin, IL 60123, USA On Wed, Jul 8, 2009 at 12:29 PM, Bryan Larsen <[email protected]>wrote: > > The rest of your code will look a lot cleaner if you have one class per > type. You can use a base class and meta programming techniques to > define 100 classes in a lot less than 100 lines of code. > > But if you don't want to do that, table and field names are available in > the this_field & this_parent parameters. see the DRYML guide for more > information on these variables. > > Bryan > > > Steve Van Bruwaene wrote: > > Thanks Bryan! > > > > Is there any way for a rich type class to be able to determine the table > > and field it's on? > > > > In my system, I have lots of different fields in lots of tables that all > > use the Translation Table. It would be nice if I could create one class > > that could figure out which records to stick in the select box rather > > than having to create classes for all 100 of them. > > > > Thanks again! > > > > Steve. > > > > -- > > Steve Van Bruwaene > > International Teams Canada > > Special Projects > > [email protected] <mailto:[email protected]> > > http://www.vanbruwaene.ca > > "Developing Resources that help IT Canada be More Effective in its > Mission." > > > > IT Canada: 519-669-8844, 1 Union St., Elmira, ON, N3B 3J9 > > IT US: 847-429-0900, 411 West River Road, Elgin, IL 60123, USA > > > > > > On Wed, Jul 8, 2009 at 9:46 AM, Bryan Larsen <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > A rich type is a class, so you can use a polymorphic tag. > > > > <def tag="input" for="Folder"> > > <select name="¶m_name_for_this"> > > <%= options_for_select this.some_function_you_created -%> > > </select> > > </def> > > > > Steve VanB wrote: > > > Thanks! This is helpful for storing and rendering the items. > > > > > > how do I create a <select> to edit them? I can't seem to find any > > > info on creating editors for rich types. > > > > > > Thanks again. > > > > > > Steve. > > > > > > On Jul 7, 9:58 am, Bryan Larsen <[email protected] > > <mailto:[email protected]>> wrote: > > >> Your ERB (or something very similar) should work in DRYML, too. > > >> > > >> Doing it at the model level will make life cleaner for you. The > > best > > >> way would be to define arich type: > > http://cookbook.hobocentral.net/manual/hobofields/rich_types > > >> > > >> My thought would be to set COLUMN_TYPE to :string to hold your > code, > > >> and then look up the translation in to_html. > > >> > > >> cheers, > > >> Bryan > > >> > > >> On Jul 7, 9:27 am, Steve VanB <[email protected] > > <mailto:[email protected]>> wrote: > > >> > > >>> I'm working with a legacy system that stores all of > > it'sselect(drop- > > >>> down) options for all fields in one table. Here's a model of > the > > >>> table: > > >>> class Translation < ActiveRecord::Base > > >>> hobo_model > > >>> set_primary_key "TranslationID" > > >>> fields do > > >>> TableName :string, :limit => 40 > > >>> FieldName :string, :limit => 40 > > >>> Code :string, :limit => 5 > > >>> Description :string, :limit => 65 > > >>> end > > >>> end > > >>> Where Table name is the name of the table the particular option > is > > >>> for, FieldName is the name of the field it's for, Code is what > > is to > > >>> be stored in the field, and Description is what's displayed in > the > > >>> drop-down. The primary key is yet another field that's not used > in > > >>> this arrangement. > > >>> So I need to be able to do a custom query for each field that > > needs a > > >>> drop-down, radio buttons, or whatever, to be able to populate it > > >>> appropriately. > > >>> I've got it working in a non-hobo rails app by adding code to > > the view > > >>> to get the data for me: > > >>> <%= folder_form.collection_select :EmailCode, Translation.find > > >>> (:all, :conditions => {:TableName => 'Folder', :FieldName => > > >>> 'EmailCode'}), :Code, :Description, :include_blank => true %> > > >>> I should be able to have something at the model layer in hobo to > do > > >>> this though. How would I do this? > > >>> Thanks! > > >>> Steve. > > >> > > > > > > > > > > > > > > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
