Re: [Hobo Users] What are the next steps for a newbie?
70 views
Skip to first unread message
Bryan Larsen
Nov 21, 2012, 8:50:13 AM11/21/12
to hobo...@googlegroups.com
Obviously, there's more than one way to do this, but here's my
suggestion. Perhaps others will chime in with different suggestions
and you can pick and choose.
Assumptions: the model that contains the CSV is called UploadedCsv,
which is used to create a bunch of records named Contract.
"business logic" in general belongs in the model. So add a method to
UploadedCsv that parses your CSV. It should be responsible for
parsing the CSV and call out to a class method on Contract responsible
for creating new contracts, checking for dupes, et cetera.
I'd expose this logic to the UI by adding a lifecycle to UploadedCsv.
2 or three states: unprocessed, processed and maybe an error state.
The transition from unprocessed to processed would call the parsing
method. Lifecycle buttons are then almost automatically added by
Hobo if you have the permissions and visibility set correctly.
suggested reading: the lifecycle chapter in Hobo, and the ActiveRecord
query interface:
http://guides.rubyonrails.org/active_record_querying.html
Bryan
On Wed, Nov 21, 2012 at 7:57 AM, Drew Hamilton <a...@awh.org> wrote:
> Hi all,
>
> First off, a very quick introduction of where I'm coming from,
> skill-level-wise: I'm a complete neophyte with both Rails and Hobo,
> although I'm familiar with Ruby. I do understand web development, MVC
> architecture, OOP, etc., and have used a variety of platforms and
> frameworks.
>
> My company needs a small internal database to keep track of contracts, and
> I'm using that as an opportunity to learn Rails. I was attracted to Hobo
> because it seems like it will eliminate a lot of the "busy work" involved in
> making an application.
>
> I did the Agility tutorial, and also followed along with my own application.
> Indeed, I was amazed at how I needed to do little more than declare my model
> to have a full application up and running. I also did some work at changing
> some of the cards for my application, just to show that I can, although I
> prefer not to do a whole lot of that until the application is more complete
> than it is.
>
> Where I'm stuck now is that after the tutorial, I have an app that allows
> users to enter and view data, but I don't have a really good understanding
> of how to make it do things programmatically.
>
> In my specific case, the contract data in my application really only needs
> to be *viewed*; the data itself should be uploaded once per month from a CSV
> file and then cleaned up, have the uploader notified of problem rows, etc.
> I used Paperclip and made a model that would take the raw CSV files, and I
> also made a model to hold the actual data from the files.
>
> Parsing the CSV isn't the problem; I'm sure there are many Ruby libraries
> that can help. What I don't know is
>
> - If I wanted to make a link in the "uploaded csv file" page that, when
> clicked would run code, how do I make that link? And where does the code
> itself go?
> - How do I access the data (not the CSV file; I mean how do I make new
> records; how do I search existing records, etc.) from that code?
>
> I'm certainly not asking anyone to do my work for me; just hoping that
> someone could give me a link that I can read, or a link to a hobo-based
> project with public source code, etc. that would help point me in the right
> direction.
>
> Thanks!
>
> - Drew
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hobo Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/hobousers/-/zvwqiZ7JjuMJ.
> To post to this group, send email to hobo...@googlegroups.com.
> To unsubscribe from this group, send email to
> hobousers+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hobousers?hl=en.
suggestion. Perhaps others will chime in with different suggestions
and you can pick and choose.
Assumptions: the model that contains the CSV is called UploadedCsv,
which is used to create a bunch of records named Contract.
"business logic" in general belongs in the model. So add a method to
UploadedCsv that parses your CSV. It should be responsible for
parsing the CSV and call out to a class method on Contract responsible
for creating new contracts, checking for dupes, et cetera.
I'd expose this logic to the UI by adding a lifecycle to UploadedCsv.
2 or three states: unprocessed, processed and maybe an error state.
The transition from unprocessed to processed would call the parsing
method. Lifecycle buttons are then almost automatically added by
Hobo if you have the permissions and visibility set correctly.
suggested reading: the lifecycle chapter in Hobo, and the ActiveRecord
query interface:
http://guides.rubyonrails.org/active_record_querying.html
Bryan
On Wed, Nov 21, 2012 at 7:57 AM, Drew Hamilton <a...@awh.org> wrote:
> Hi all,
>
> First off, a very quick introduction of where I'm coming from,
> skill-level-wise: I'm a complete neophyte with both Rails and Hobo,
> although I'm familiar with Ruby. I do understand web development, MVC
> architecture, OOP, etc., and have used a variety of platforms and
> frameworks.
>
> My company needs a small internal database to keep track of contracts, and
> I'm using that as an opportunity to learn Rails. I was attracted to Hobo
> because it seems like it will eliminate a lot of the "busy work" involved in
> making an application.
>
> I did the Agility tutorial, and also followed along with my own application.
> Indeed, I was amazed at how I needed to do little more than declare my model
> to have a full application up and running. I also did some work at changing
> some of the cards for my application, just to show that I can, although I
> prefer not to do a whole lot of that until the application is more complete
> than it is.
>
> Where I'm stuck now is that after the tutorial, I have an app that allows
> users to enter and view data, but I don't have a really good understanding
> of how to make it do things programmatically.
>
> In my specific case, the contract data in my application really only needs
> to be *viewed*; the data itself should be uploaded once per month from a CSV
> file and then cleaned up, have the uploader notified of problem rows, etc.
> I used Paperclip and made a model that would take the raw CSV files, and I
> also made a model to hold the actual data from the files.
>
> Parsing the CSV isn't the problem; I'm sure there are many Ruby libraries
> that can help. What I don't know is
>
> - If I wanted to make a link in the "uploaded csv file" page that, when
> clicked would run code, how do I make that link? And where does the code
> itself go?
> - How do I access the data (not the CSV file; I mean how do I make new
> records; how do I search existing records, etc.) from that code?
>
> I'm certainly not asking anyone to do my work for me; just hoping that
> someone could give me a link that I can read, or a link to a hobo-based
> project with public source code, etc. that would help point me in the right
> direction.
>
> Thanks!
>
> - Drew
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hobo Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/hobousers/-/zvwqiZ7JjuMJ.
> To post to this group, send email to hobo...@googlegroups.com.
> To unsubscribe from this group, send email to
> hobousers+...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/hobousers?hl=en.
Ignacio Huerta
Nov 21, 2012, 9:50:55 AM11/21/12
to hobo...@googlegroups.com
Hi,
Bryan's suggestions are very good. In your case, I would suggest
starting with a basic code to get a mental picture of the whole Rails app:
- Make the link point to "/files/1/parse". Edit the "show.dryml" page
for this.
- Add a route to config/routes.rb to match this link to the action
"parse" in the controller "FilesController"
- Add the action parse in the "FilesController" (using logger.info and
monitoring the log will help to know if you are on the right way).
- Inside the action: run your code and redirect the user to somewhere.
- Try not to put too much code inside the action. It's much better to
call model methods. But as a start, just make it work :). The "fat
models, thin controllers" philosophy will come later.
A couple of examples of show_pages in Hobo apps:
-
https://github.com/suyccom/member-manage/blob/master/app/views/members/show.dryml
-
https://github.com/suyccom/agility_bootstrap/blob/master/app/views/projects/show.dryml
To make all this happen, I would browse Rails official docs or even
better, grab a copy of the book "Agile Web Development with Rails" (4th
edition is for Rails 3) .
Regards,
Ignacio
El 21/11/12 14:50, Bryan Larsen escribi�:
--
Ignacio Huerta Arteche
http://www.ihuerta.net
Tel�fono: 0034 645 70 77 35
Email realizado con software libre
Bryan's suggestions are very good. In your case, I would suggest
starting with a basic code to get a mental picture of the whole Rails app:
- Make the link point to "/files/1/parse". Edit the "show.dryml" page
for this.
- Add a route to config/routes.rb to match this link to the action
"parse" in the controller "FilesController"
- Add the action parse in the "FilesController" (using logger.info and
monitoring the log will help to know if you are on the right way).
- Inside the action: run your code and redirect the user to somewhere.
- Try not to put too much code inside the action. It's much better to
call model methods. But as a start, just make it work :). The "fat
models, thin controllers" philosophy will come later.
A couple of examples of show_pages in Hobo apps:
-
https://github.com/suyccom/member-manage/blob/master/app/views/members/show.dryml
-
https://github.com/suyccom/agility_bootstrap/blob/master/app/views/projects/show.dryml
To make all this happen, I would browse Rails official docs or even
better, grab a copy of the book "Agile Web Development with Rails" (4th
edition is for Rails 3) .
Regards,
Ignacio
El 21/11/12 14:50, Bryan Larsen escribi�:
Ignacio Huerta Arteche
http://www.ihuerta.net
Tel�fono: 0034 645 70 77 35
Email realizado con software libre
Bryan Larsen
Nov 21, 2012, 10:28:03 AM11/21/12
to hobo...@googlegroups.com
Ignacio,
I think you should take a second look at Lifecycles. By using a
lifecycle, Hobo automatically generates controller actions and views.
But more importantly, lifecycles encourage structuring your code as a
state machine. I'm biased because I used to be an Electronic
Engineer in a past life, but I love state machines.
Most solutions to Drew's problem involve some sort of explicit or
implicit state on a file -- it's either parsed or unparsed. Using an
explicit state machine to describe it makes the code a lot cleaner,
IMO.
It's my rule of thumb that all controller actions should:
1) be create, update or destroy
2) multiple show & index actions are OK
3) be a lifecycle action
In other words REST + a state machine should be good enough for 99.9%
of all controller actions.
Drew: this advice is for Ignacio. Ignacio's advice of "just get it
to work before worrying about style" applies to you.
Ignacio: don't take my advice as criticism. I know you're good at
what you do and probably don't need the advice. I just couldn't
resist a chance to pontificate.
Bryan
On Wed, Nov 21, 2012 at 9:50 AM, Ignacio Huerta <ign...@ihuerta.net> wrote:
> Hi,
>
> Bryan's suggestions are very good. In your case, I would suggest starting
> with a basic code to get a mental picture of the whole Rails app:
>
> - Make the link point to "/files/1/parse". Edit the "show.dryml" page for
> this.
> - Add a route to config/routes.rb to match this link to the action "parse"
> in the controller "FilesController"
> - Add the action parse in the "FilesController" (using logger.info and
> monitoring the log will help to know if you are on the right way).
> - Inside the action: run your code and redirect the user to somewhere.
> - Try not to put too much code inside the action. It's much better to call
> model methods. But as a start, just make it work :). The "fat models, thin
> controllers" philosophy will come later.
>
>
> A couple of examples of show_pages in Hobo apps:
> -
> https://github.com/suyccom/member-manage/blob/master/app/views/members/show.dryml
> -
> https://github.com/suyccom/agility_bootstrap/blob/master/app/views/projects/show.dryml
>
> To make all this happen, I would browse Rails official docs or even better,
> grab a copy of the book "Agile Web Development with Rails" (4th edition is
> for Rails 3) .
>
> Regards,
> Ignacio
>
> El 21/11/12 14:50, Bryan Larsen escribió:
> Teléfono: 0034 645 70 77 35
I think you should take a second look at Lifecycles. By using a
lifecycle, Hobo automatically generates controller actions and views.
But more importantly, lifecycles encourage structuring your code as a
state machine. I'm biased because I used to be an Electronic
Engineer in a past life, but I love state machines.
Most solutions to Drew's problem involve some sort of explicit or
implicit state on a file -- it's either parsed or unparsed. Using an
explicit state machine to describe it makes the code a lot cleaner,
IMO.
It's my rule of thumb that all controller actions should:
1) be create, update or destroy
2) multiple show & index actions are OK
3) be a lifecycle action
In other words REST + a state machine should be good enough for 99.9%
of all controller actions.
Drew: this advice is for Ignacio. Ignacio's advice of "just get it
to work before worrying about style" applies to you.
Ignacio: don't take my advice as criticism. I know you're good at
what you do and probably don't need the advice. I just couldn't
resist a chance to pontificate.
Bryan
On Wed, Nov 21, 2012 at 9:50 AM, Ignacio Huerta <ign...@ihuerta.net> wrote:
> Hi,
>
> Bryan's suggestions are very good. In your case, I would suggest starting
> with a basic code to get a mental picture of the whole Rails app:
>
> - Make the link point to "/files/1/parse". Edit the "show.dryml" page for
> this.
> - Add a route to config/routes.rb to match this link to the action "parse"
> in the controller "FilesController"
> - Add the action parse in the "FilesController" (using logger.info and
> monitoring the log will help to know if you are on the right way).
> - Inside the action: run your code and redirect the user to somewhere.
> - Try not to put too much code inside the action. It's much better to call
> model methods. But as a start, just make it work :). The "fat models, thin
> controllers" philosophy will come later.
>
>
> A couple of examples of show_pages in Hobo apps:
> -
> https://github.com/suyccom/member-manage/blob/master/app/views/members/show.dryml
> -
> https://github.com/suyccom/agility_bootstrap/blob/master/app/views/projects/show.dryml
>
> To make all this happen, I would browse Rails official docs or even better,
> grab a copy of the book "Agile Web Development with Rails" (4th edition is
> for Rails 3) .
>
> Regards,
> Ignacio
>
> Email realizado con software libre
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Hobo Users" group.
> You received this message because you are subscribed to the Google Groups
> "Hobo Users" group.
Ignacio Huerta
Nov 21, 2012, 11:44:22 AM11/21/12
to hobo...@googlegroups.com
Hi Bryan,
Thank you very much! Your insights are really inspiring, please do it as
often as you feel. It is very
I'm definitely going to take another look at lifecycles. I've been using
them a lot, but I hadn't realised that REST + state machine could cover
so many possibilities.
Talking about coding style, do you have any "rule" when using multiple
show&index actions? I usually create actions called something like
"main_report", which are actually very similar to an index action, just
tuned with some queries and graphs.
Regards,
Ignacio
El 21/11/12 16:28, Bryan Larsen escribi�:
>> El 21/11/12 14:50, Bryan Larsen escribi�:
>> Tel�fono: 0034 645 70 77 35
Thank you very much! Your insights are really inspiring, please do it as
often as you feel. It is very
I'm definitely going to take another look at lifecycles. I've been using
them a lot, but I hadn't realised that REST + state machine could cover
so many possibilities.
Talking about coding style, do you have any "rule" when using multiple
show&index actions? I usually create actions called something like
"main_report", which are actually very similar to an index action, just
tuned with some queries and graphs.
Regards,
Ignacio
El 21/11/12 16:28, Bryan Larsen escribi�:
>> Email realizado con software libre
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Hobo Users" group.
>> To post to this group, send email to hobo...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hobousers+...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hobousers?hl=en.
>>
>
--
Ignacio Huerta Arteche
http://www.ihuerta.net
Tel�fono: 0034 645 70 77 35
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Hobo Users" group.
>> To post to this group, send email to hobo...@googlegroups.com.
>> To unsubscribe from this group, send email to
>> hobousers+...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/hobousers?hl=en.
>>
>
--
Ignacio Huerta Arteche
http://www.ihuerta.net
Bryan Larsen
Nov 21, 2012, 11:51:06 AM11/21/12
to hobo...@googlegroups.com
> Talking about coding style, do you have any "rule" when using multiple
> show&index actions?
Maybe I should, but I don't. :)
> show&index actions?
cheers,
Bryan
kevinpfromnm
Nov 21, 2012, 7:57:30 PM11/21/12
to hobo...@googlegroups.com
+1 on lifecycle to encapsulate the parse and expose action on controller/view.
1 downside of the link is unless you know your routes well, you'll probably make it respond to GET request. My general rule with HTML is a link should never trigger a (significant?) change because robots will follow them.
1 downside of the link is unless you know your routes well, you'll probably make it respond to GET request. My general rule with HTML is a link should never trigger a (significant?) change because robots will follow them.
Owen
Nov 22, 2012, 9:21:45 AM11/22/12
to hobo...@googlegroups.com
This would be a nice recipe to share with others when you have it all worked out...
Drew Hamilton
Jan 8, 2013, 12:55:00 AM1/8/13
to hobo...@googlegroups.com
Hello all,
Thank you for all your suggestions. I know it's been a while but I was on a road/sea trip for several weeks without reliable access to the Internet, so I would just work for a while, get stuck, and then wait until I next had Internet to look up what the problem was so I could keep going.
Here is where I am at, and it's led to more questions:
1. I have a "data uploads" model that contains the uploaded file itself.
2. Each data_upload has_many "import rows"; the import rows table is just a "square" table of text that the Excel file gets parsed into.
3. There is a lifecycle action on the data uploads table that takes "uploaded" rows and turns them into "parsed" rows -- that essentially makes several "import rows" based on the uploaded data.
4. My "real" model (not the Import stuff) has computer manufacturers and model numbers. Each table also has an "aliases" table ("HP", "Compaq", "HP/Compaq" are all aliases for "Hewlett Packard", for example). I made methods on the models that would look up records "by name or alias".
5. Another lifecycle action on the data uploads table turns "parsed" rows into "imported" ones, by checking for the existence of manufacturers or models, and creating them if they do not exist yet.
Now I have more questions:
1. Is there any way to programatically "back out of" changing states in a lifecycle, if something goes wrong along the way? Or having a single action decide halfway which of two possible states that should be the result. During development I am just changing things back directly in the database, but it seems like the state gets changed at the beginning of the action.
2. Each manufacturer has_many manufacturer_aliases and also has_many models. manufacturer_aliases and models both have create auto_action for manufacturers, but only one of them works. Which one works depends on which one is the first "children" of manufacturer. Is this expected behaviour?
3. Is there any way to interact with the user in the middle of the lifecycle action? Rather than just blindly creating new entries for things that it comes across and can't find, I'd like to ask whether it's a new manufacturer or an alias of an existing one.
Thanks,
- Drew
Ignacio Huerta
Jan 8, 2013, 2:26:32 AM1/8/13
to hobo...@googlegroups.com, Drew Hamilton
Hi Drew,
El 08/01/13 06:55, Drew Hamilton escribi�:
I'm not sure how to do this in the model, but I guess you could use
something like this in the controller:
def do_my_transition
invoice = Invoice.find(params[:id])
if (... some conditions ...)
do_transition_action :my_transition
else
flash[:error] = "There has been an error"
redirect_to(:action => 'show')
end
end
>
> 2. Each manufacturer has_many manufacturer_aliases and also has_many
> models. manufacturer_aliases and models both have create auto_action
> for manufacturers, but only one of them works. Which one works depends
> on which one is the first "children" of manufacturer. Is this expected
> behaviour?
Yes, I think so. The automatic generator that creates
app/views/taglibs/auto/pages.dryml only prepares the form for the first
one. But you should be able to add another form in show.dryml. Just take
a look at the automatic page and see if you can reuse that. Ask if you
get stuck :).
>
> 3. Is there any way to interact with the user in the middle of the
> lifecycle action? Rather than just blindly creating new entries for
> things that it comes across and can't find, I'd like to ask whether it's
> a new manufacturer or an alias of an existing one.
I'm not sure how your code looks like now, but I'm pretty sure you can
do this in the model or controller levels. If you don't see how, please
post the code that created the new records during the transition.
Regards,
Ignacio
El 08/01/13 06:55, Drew Hamilton escribi�:
something like this in the controller:
def do_my_transition
invoice = Invoice.find(params[:id])
if (... some conditions ...)
do_transition_action :my_transition
else
flash[:error] = "There has been an error"
redirect_to(:action => 'show')
end
end
>
> 2. Each manufacturer has_many manufacturer_aliases and also has_many
> models. manufacturer_aliases and models both have create auto_action
> for manufacturers, but only one of them works. Which one works depends
> on which one is the first "children" of manufacturer. Is this expected
> behaviour?
app/views/taglibs/auto/pages.dryml only prepares the form for the first
one. But you should be able to add another form in show.dryml. Just take
a look at the automatic page and see if you can reuse that. Ask if you
get stuck :).
>
> 3. Is there any way to interact with the user in the middle of the
> lifecycle action? Rather than just blindly creating new entries for
> things that it comes across and can't find, I'd like to ask whether it's
> a new manufacturer or an alias of an existing one.
do this in the model or controller levels. If you don't see how, please
post the code that created the new records during the transition.
Regards,
Ignacio
> --
> You received this message because you are subscribed to the Google
> Groups "Hobo Users" group.
> To view this discussion on the web visit
> https://groups.google.com/d/msg/hobousers/-/8N0HtSC879wJ.
> You received this message because you are subscribed to the Google
> Groups "Hobo Users" group.
> To view this discussion on the web visit
Owen Dall
Jan 8, 2013, 7:45:33 AM1/8/13
to hobo...@googlegroups.com
THis will be a very useful recipe to share...
--
On Tue, Jan 8, 2013 at 2:26 AM, Ignacio Huerta <ign...@ihuerta.net> wrote:
Hi Drew,
El 08/01/13 06:55, Drew Hamilton escribió:
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
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 post to this group, send email to hobo...@googlegroups.com.
To unsubscribe from this group, send email to hobousers+unsubscribe@googlegroups.com.
-Owen
Owen Dall
Vice President | Chief Technology Officer
Barquin International
Office: 202.296.7147 | Mobile: tel:410.991.0811
Fax: 202.296.8903 | email: od...@barquin.com
T. Schulz
Jan 21, 2013, 8:38:43 AM1/21/13
to hobo...@googlegroups.com
Hallo!
Please can so wrote me a link to
Where can I find and download the newest version of 'Hobo at work' for the latest RoR-Versions
Regards
Torsten Schulz
Postfach 1804
38288 Wolfenbüttel
Germany
Reply all
Reply to author
Forward
0 new messages