Re: Possible changes to simplify use

16 views
Skip to first unread message

TechnoSophos

unread,
Dec 10, 2012, 10:30:05 AM12/10/12
to devel-q...@googlegroups.com
Enrique,

Your suggestion prompted two ideas from me.

The first is that you pointed out a very common use case that I may be able to accommodate: Adding an element and then adding some attributes. I might be able to do something like append('<a/>', array('href' => '/foo', 'class' => 'bar')) or something like that.

The second is adding a new append-like method -- something like appendAndFocus(), prependAndFocus() or maybe something shorter. Since it is just as common a pattern to add a whole bunch of elements under one (imagine building a ul or li items), you are right that another common use case is appending and then getting the appended element and working with that.

Thoughts?

Feel free to file an issue on GitHub (https://github.com/technosophos/querypath), and I'll track it as a task in there.

Thanks for the suggestions!

Best,

Matt

-- 
TechnoSophos
Twitter: @technosophos
Sent with Sparrow

On Friday, December 7, 2012 at 10:56 AM, Enrique wrote:

Hi, I am new to QueryPath. I was greatly surprised about its power and simplicity. I used it for a metasearch experiment (reading results of different search engines, processing them, and presenting results in uniform way). 

I have never used jQuery, so I'm not polluted by it :-) Using QueryPath, I realized that I have to repeat certain patterns, and I guess everybody will happen the same. 

For example, to put a hyperlink in the middle of a larger document edition, I have to write:
   ...
   ->append('<a/>')
    ->find('a:first')
     ->attr('href', $enlace)
     ->text($titulo)
    ->end() ...

I like very much how QueryPath works, but I also expected a more simple use indeed. At first sight I would like that append(element) and prepend(element) do also the find(element:last) or find(element:first), or the neccesary find(...) to select the appended elements automatically. It would be simmilar to the idea of RPN (Reverse Polish Notation), that is: 
  1. select the operands, 
  2. apply operation to that elements, 
  3. the result of operation becomes the new selected elements.
I would also like that these methods write just the tag element, empty and closed, for example 
  append('a'),
would write "<a></a>", leaving the writing of content of that elements to text(). That way would avoid programmer errors and would separate funcionality. 

Now we can use
   append('<p>Hello</p>') 
and
   html('<p>Hello</p>') 
with the same results. It is not good to have that redundancy. If we want to write the whole element with attributes and content, the right way would be to use html(), not append().

I notice that one of the most important criteria in the design and evolution of QueryPath is to be very close to the jQuery functions. I understand this criteria in order that jQuery programmers feel comfort with QueryPath. But I think that QueryPath could be better ;-) (at least for the people that don't know jQuery), and this criteria is a limitation to improve and simplify QueryPath. 

Perhaps it would be better to start a (experimental) fork of QueryPath with the criteria of simplicity of use, less functions (avoid redundancy of behaviour in different functions), minimize the user code, use RPN like behaviour, etc

What do you think?

--
You received this message because you are subscribed to the Google Groups "devel-querypath" group.
To view this discussion on the web visit https://groups.google.com/d/msg/devel-querypath/-/GWyTAWSK1ooJ.
To post to this group, send email to devel-q...@googlegroups.com.
To unsubscribe from this group, send email to devel-querypa...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/devel-querypath?hl=en.

Reply all
Reply to author
Forward
0 new messages