I personally don't see why it is such a bad thing to utilize. Technically
its not returning an array, its an Elements object. So there is a lot of
flexibility that comes with it. All the cases you describe that create
errors are bad form if you don't have sanity checking on your data if you
know the structure is changing.
honestly, I find the race conditions with loading scripts with ajax more
scary. Personally I would opt to do something like this:
respElements.each(function(el){
if(el.hasClass('attach')) new MyFancyBehavior(el);
});
then pass a script along the response that does this.
I think responseElements is just a byproduct of how Request.HTML works, its
not an expensive operation and is practically there to begin with. I do
think there are cases where it is handy to have things in a flattened array.
just my 2 cents.
2009/7/20 Fábio M. Costa <fabiomco...@gmail.com>
> Thats what i wanna know, if ppl use it.
> Anybody else?
>
> It could be more useful if it would be a Javascript Object indexed by the
> id of the nodes, but imagine the processing on a bug response...
>
> An array of nodes from the response... if someone uses it hes doing a bad
> thing, if you change the order of the response nodes or add any node you
> will crash your clientcide(tm) code.
>
> For me its useless and i think people should avoid its use.
>
> Im just saying, thats my point of view...
>
>
> Fábio Miranda Costa
> Solucione Sistemas
> Front-End Engineer
> http://meiocodigo.com
>
>
> On Mon, Jul 20, 2009 at 3:29 PM, Aaron Newton <aa...@iminta.com> wrote:
>
>> no, but that doesn't mean others do not.
>>
>>
>> 2009/7/20 Fábio M. Costa <fabiomco...@gmail.com>
>>
>>> did you ever used responseElements?
>>>
>>>
>>> Fábio Miranda Costa
>>> Solucione Sistemas
>>> Front-End Engineer
>>> http://meiocodigo.com
>>>
>>>
>>> On Mon, Jul 20, 2009 at 2:58 PM, Aaron Newton <aa...@iminta.com> wrote:
>>>
>>>> It's not like I do hundreds of Request.HTML fetches in an app in side of
>>>> a few seconds. The rate limit here is the bandwidth IO, not the JS engine
>>>> parsing the response tree.
>>>>
>>>> 2009/7/20 Fábio M. Costa <fabiomco...@gmail.com>
>>>>
>>>> I said that because i dont like the processing thats done on HTML.
>>>>> In a project im doing, i needed it once, and it was because there was a
>>>>> script tag on the response.
>>>>>
>>>>> Thats the good thing about it, the evalution, but i dont like the
>>>>> responseTree and the responseElements. Maybe responseTree is ok but
>>>>> responseElements is totally unnecessary, IMHO, and is the most expensive
>>>>> one
>>>>> in terms of processing.
>>>>>
>>>>> What do you guys think about them, have you guys used them
>>>>> (responseTree, responseElements)?
>>>>>
>>>>>
>>>>>
>>>>> Fábio Miranda Costa
>>>>> Solucione Sistemas
>>>>> Front-End Engineer
>>>>> http://meiocodigo.com
>>>>>
>>>>>
>>>>> On Mon, Jul 20, 2009 at 8:05 AM, Rolf <plentyofr...@gmail.com> wrote:
>>>>>
>>>>>>
>>>>>> As a general rule of thumb I use:
>>>>>> - Request.HTML when I need to update a div. Mainly real basic stuff
>>>>>> that can't go wrong.
>>>>>> - When I don't know what type the response will be I use Request and
>>>>>> figure out what to do with the response.
>>>>>> - For JSON I use Request.JSON (really! hehe).
>>>>>>
>>>>>> However, I almost never use onComplete, but onSuccess and/or onFailed
>>>>>> (if applicable) for handling the follow ups.
>>>>>> Why? Because my PHP backend could generate a "result failed" response,
>>>>>> and I have to tackle that in my onSuccess. You won't see that in your
>>>>>> onComplete and you might update a div with an error ;)
>>>>>>
>>>>>> I don't agree with Fabio either when it comes to destroying
>>>>>> Request.HTML.
>>>>>>
>>>>>>
>>>>>> On Jul 20, 9:43 am, NETTuno web <nettuno...@gmail.com> wrote:
>>>>>> > Usually i use Request.HTML and "update" to refresh the html content
>>>>>> of
>>>>>> > a div. This time i had to handle the answer, that's why i did use
>>>>>> > "onComplete" response.
>>>>>> >
>>>>>> > On 20 Lug, 01:48, Ryan Florence <rpflore...@gmail.com> wrote:
>>>>>> >
>>>>>> > > I guess I've sort of got a question.
>>>>>> >
>>>>>> > > When I use Request.HTML all I ever want to do is update a div:
>>>>>> >
>>>>>> > > var req = new Request.HTML({
>>>>>> > > url: 'file.php',
>>>>>> > > update: $('updateMe')
>>>>>> >
>>>>>> > > });
>>>>>> >
>>>>>> > > If want more than that I use Request.JSON and then provide some
>>>>>> sort
>>>>>> > > of logic onComplete to deal with the data.
>>>>>> >
>>>>>> > > When I see people grabbing the response onComplete and then having
>>>>>> a
>>>>>> > > div adopt it I scratch my head and wonder why they don't just use
>>>>>>
>>>>>> > > 'update'?
>>>>>> >
>>>>>> > > Am I missing out on something?
>>>>>> >
>>>>>> > > On Jul 19, 2009, at 3:38 PM, Aaron Newton wrote:
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>
