Hi Don,

I'm glad you found a workaround. I have reproduced the issue with your
repository and indeed it seems we have one or two bugs:

- After an Ajax update "Rails style", it looks like the data-rapid
events are not set or something similar.
- I tried to rewrite the code with an Ajax update "Hobo style" (with
parts), but I get an error the part is not being found.

This needs more time, so I'm creating an issue in Github. I'll come back
to this.

Warm regards,
Ignacio

El 27/09/14 a las #4, Donald Ziesig escribió:
> Hi All!
> 
> This turns out to be two separate issues.  The <a> tag in dryml does not
> work consistently (except to produce an HTML request when called from
> within a partial).  I replaced it with a new tag <ajax-button>.  This is
> not quite finished (it does not check for missing but required
> attributes), but it works whether it is called from an normal page or a
> partial (and always produces a JS request):
> 
> <def tag="ajax-button" attrs="label, image, subsite, action, title,
> imgclass">
> <%=  url = object_url(this, :method => :put, :subsite => subsite);
> url = url + '/' + action if action;
> link_to(url, :remote => true,:method => :put ) do
>   image_tag(image, class: imgclass, title: title);
> end %>
> </def>
> 
> Invoked with:
> 
> <ajax-button action="up" image="up-arrow.png" title="Move UP"
> imgclass="arrow-button" if="&can_edit?"/>
> 
> Note the method => :put.  This was another area where the <a> tag has a
> bug.  The only way I could get the <a> tag buttons to be active at all
> was to use :get in the <a> tag and in the associatd routes.  With the
> <ajax-button> tag, :put works in the tag and the routes.
> 
> The second issue was what appears to be a rails bug.  I was updating
> records in a belongs_to model but the changes were not propagating to
> the associated has_many model.  The fix was easy, but finding it was
> not.  All I needed was to call reload on the association after changing
> the associated data.  I was using a pattern that I used in Rails 2 (but
> not since) which worked then without needing the call to reload.  I got
> to the point that I posted a question to StackOverflow, then answered my
> own question after a lot of googling.
> 
> Don Ziesig
> 
> On 09/25/2014 09:44 PM, Donald Ziesig wrote:
>> Hi Ignacio,
>>
>> I extracted the failing code and put it into github.  Check
>> [email protected]:dziesig/demo_ajax_button_problem.git
>>
>> The code is partially completed, I got to this point when I hit the
>> problem.  Open the agenda, the show page illustrates the problem. 
>> Click on any one of the Up Arrow buttons (except the top one),  the
>> behaviour is correct.  Click it again and see the problem.  The Down
>> Arrow buttons have a slightly different problem of their own, but I
>> think once I get the Up working properly the Down will follow quickly.
>>
>> The files up.html.erb and down.html.erb are there only because I got
>> "template missing" errors on the second button click without them.
>>
>> Meanwhile, I am going to try to figure out why the second and later
>> button clicks show as HTML rather than JS.
>>
>> Thanks,
>>
>> Don
>>
>> P.S.  In the source application, I ran into the failure in rendering
>> partials from dryml on the second try that I described a long while
>> ago.  The somewhat convoluted code in this demo is part of my attempt
>> to work around that issue.
>>
>>
>>
>>
>>
>> On 09/25/2014 05:28 PM, Ignacio Huerta wrote:
>>> Sorry Don, I could not follow your example :S. It's indeed a weird
>>> bug. I suggest:
>>>
>>> * If you want to use Dryml and Ajax updates, it might be better to
>>> use the <div part="something">...<a updates="#something"... syntax
>>> * For updates with Jquery and Rails style, it might work easier a
>>> small partial in ERB/Haml
>>> * Still, it would be interesting to reproduce your issue, so if you
>>> can provide some dummy code to reproduce, I'll be glad to play around
>>>
>>> Warm regards,
>>> Ignacio
>>>
>>> On Thu, Sep 25, 2014 at 10:35 PM, Donald Ziesig <[email protected]
>>> <mailto:[email protected]>> wrote:
>>>
>>>     Hi Ignacio!
>>>
>>>     The html_safe almost works.  (I tried that but put it in the
>>>     wrong place :-[ ).
>>>
>>>     Now the only problem is much stranger.
>>>
>>>     When I click the button once, it generates a JS response and the
>>>     page renders correctly with appropriate data changes.  The second
>>>     and all subsequejt times I click it generates an HTML response
>>>     and the page renders without the data outside the <def> and with
>>>     no styling.  The data that is displayed is correct, it just looks
>>>     funny =-O .  I did have to add an html template to get this far,
>>>     without it I just get a missing template exception.  I didn't
>>>     think I would have needed the html and I would really like to get
>>>     the buttons to always generate JS like the first time.
>>>
>>>     It must have something to do with context because the html for
>>>     the button stays the same in firebug, it just works without ajax
>>>     on all clicks but the first.
>>>
>>>     Any Ideas?
>>>
>>>     Don
>>>
>>>
>>>     On 09/25/2014 12:06 PM, Ignacio Huerta wrote:
>>>
>>>         Hi Don,
>>>
>>>         Your HTML is being escaped. You need something like this:
>>>
>>>         $('#agenda_items').html('<%=j render(:partial =>
>>>         'agendas/table_plus',
>>>         :locals => { :this => @this }).html_safe %>');
>>>
>>>         You can also use "raw(html_string)" I think.
>>>
>>>         Please say if this doesn't help :)
>>>
>>>         Regards,
>>>         Ignacio
>>>
>>>         El 25/09/14 a las #4, Donald Ziesig escribió:
>>>
>>>             Another strange one:
>>>
>>>             I am trying to render a partial (dryml) from javascript. 
>>>             The javascript
>>>             is a one-liner:
>>>
>>>             $('#agenda_items').html('<%=j render :partial =>
>>>             'agendas/table_plus',
>>>             :locals => { :this => @this } %>');
>>>
>>>             The partial is also rather trivial:
>>>
>>>                  <table-plus with="&this.agenda_items"
>>>             fields="position, this">
>>>             <controls:><controls-with-up-dn/></controls:>
>>>                  </table-plus>
>>>
>>>             Unfortunately, in the <div id="agenda_items" > ... </div>
>>>
>>>             Instead of the table-plus and all its entries being
>>>             rendered, the html
>>>             (correct as near as I can tell) is rendered as text:
>>>
>>>             <div class="table-plus"><div class="header"><div
>>>             class="search"> <form
>>>             action="" class="search-form" method="get"><div
>>>             class="hidden-fields"></div> <span
>>>             class="label">Search</span> <input
>>>             class="search" name="search" type="search"><input
>>>             class="button
>>>             submit-button search-button search-submit" type="submit"
>>>             value="Go"></form> </div></div> <table> <thead><tr
>>>             class="field-heading-row"> <th class="position-heading"> <a
>>>             class="column-sort position-heading-link"
>>>             href="/agenda_items/4-approval-of-last-month-s-minutes/ ****
>>>
>>>             The code in the partial renders correctly when invoked
>>>             directly.
>>>
>>>             What am I missing?
>>>
>>>             Thanks,
>>>
>>>             Don Ziesig
>>>
>>>
>>>     -- 
>>>     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]
>>>     <mailto:hobousers%[email protected]>.
>>>     To post to this group, send email to [email protected]
>>>     <mailto:[email protected]>.
>>>     Visit this group at http://groups.google.com/group/hobousers.
>>>     For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>>
>>>
>>> -- 
>>> Ignacio Huerta Arteche
>>> http://www.ihuerta.net
>>> 0034 645 70 77 35
>>> -- 
>>> 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]
>>> <mailto:[email protected]>.
>>> To post to this group, send email to [email protected]
>>> <mailto:[email protected]>.
>>> Visit this group at http://groups.google.com/group/hobousers.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> -- 
>> 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]
>> <mailto:[email protected]>.
>> To post to this group, send email to [email protected]
>> <mailto:[email protected]>.
>> Visit this group at http://groups.google.com/group/hobousers.
>> For more options, visit https://groups.google.com/d/optout.
> 
> -- 
> 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]
> <mailto:[email protected]>.
> To post to this group, send email to [email protected]
> <mailto:[email protected]>.
> Visit this group at http://groups.google.com/group/hobousers.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/d/optout.

Reply via email to