Sounds great Txinto, keep us informed.

I have created a Github issue to improve the Hobo generators:
https://github.com/Hobo/hobo/issues/51

Regards,
Ignacio

El 10/12/13 16:54, Txinto Vaz escribió:
> I am trying to translate a Redmine classic plugin to Redmine plugin
> "made with Hobo".
> 
> I have created a vanilla Redmine installation with a Hobo fork included,
> to be able to make the plugin work and to patch Hobo.
> 
> Probably I will find a lot of obstacles in my way.  I am using a Redmine
> project and two github repositories to track this, so anyone can see the
> way and download the sources.
> 
> You can find information here:
> 
> http://gatatac.org/issues/49
> http://gatatac.org/issues/50
> 
> Currently I am "in progress", but I will disturb you if I am in a pitfall.
> 
> Best regards from the storm that is currently coming to the Canaries.
> 
> Tx.
> 
> El martes, 10 de diciembre de 2013 12:04:34 UTC, txinto escribió:
> 
>     Hi again.
> 
>     If I add an empty app/views/taglibs/application.dryml to the project
>     it works fine if I add the hobo gem to the bundle.
> 
>     Thanks a lot, I will continue working.  I think next thing to do is
>     to prepare a vanilla installation of Redmine with my current
>     hobo-plugin development and upload it to github in order to have a
>     vehicle for testing and sharing the improvements.
> 
>     Maybe the best option is to include the hobo as plugin (not a gem)
>     in the Redmine installation so the hobo itself can be patched to add
>     Redmine specific features.
> 
>     Thanks a lot.
> 
>     Tx.
> 
> 
>     2013/12/9 Txinto Vaz <[email protected] <javascript:>>
> 
>         Hi again.  Thanks in advance for your help and feedback.
>          
> 
>             About this problem, what happens if you create an empty
>             app/views/taglibs/application.dryml?
> 
> 
>         I will make a try and keep you informed.
>          
>         The hobo_migrations should have to know about the changes
>         introduced in plugin migration.  I don't know what is exactly
>         the mechanism to know how to calculate the migration, but
>         probably it is comparing the result of the schema.rb with the
>         sum of the migrations and, then, try to add/drop all the tables
>         that are not present in both places.  In my opinion and taking
>         this example as basis, the sum of migrations need to include the
>         migrations in the plugin subdirectories
>         (plugin/n-plugin/db/migrate/*).  This is difficult to do,
>         because Redmine puts the plugins in plugins/ directory, but
>         Rails puts the plugins in another place.  So maybe this can be
>         done setting an option like --include-plugin-migrations
>         --plugin-directory-root=./plugins
> 
>             What do you think if we add an option to the generator like
> 
>             "-never-drop" so it just ignores the "extra" tables?
> 
> 
>         Fantastic!!!  This can be understood as a workaround or as the
>         way to do it.  In this second scenario, then the hobo g
>         migration should be executed in different places: in rails root
>         and in the myplugin subdirectory.  In the first scenario (I
>         think is more difficult to make it work) a hobo g migration in
>         rails root will also calculate migrations for all plugins using
>         hobo_fields.
> 
>             This sounds reasonable. I suppose you are referring to
>             something like:
> 
>              hobo g resource event name:string -d plugins/superplugin
> 
>             So models are created into plugins/superplugin/app/
>             models. Is this right?
> 
> 
>         Absolutely.  And this can be the key to solve easily most of the
>         abovementioned the problems.  The hobo generators can probably
>         create an intermediate file containing all the directories that
>         include a migration, so it can be used later by hobo migration
>         to know what to take into account.
> 
>              That's interesting, I wonder why it's trying to add a limit
>             4 for these
> 
>             columns. I've searched Hobo's source and I didn't find
>             anything on first
>             look. What database are you using?
> 
> 
>         In this deployment I use MySQL,
>          
> 
>             A workaround could be to add an option
>             "ignore-column-attributes" so the
>             generator just stops changing those columns. What do you think?
> 
> 
>         Fantastic again!
> 
>         Thanks a lot for your help.
> 
>         Tx.
> 
> 
> -- 
> You received this message because you are subscribed to the Google
> Groups "Hobo Users" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/hobousers.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
Ignacio Huerta Arteche
http://www.ihuerta.net
Teléfono: 0034 645 70 77 35
Email realizado con software libre

-- 
You received this message because you are subscribed to the Google Groups "Hobo 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/hobousers.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to