Simple question, in terms of best practice is it better to format my URL like this:
http://www.example.com/search?query=hello&page=1
or like this:
http://www.example.com/search/hello/page/1
Can you provide a valid reason for your choice please.
First one fits the situation where you want to "filter" your result if it gets a little too complicated, like this example:
cars.com/audi/sedan/a/4/black/manual.....
this is gonna take so long and complicated and result will be nightmare, but this would work better:
cars.com/mercedes/amg?color=white&transmission=manual
2nd way is just like thinking it of a 'folder'ed structure:
socialmedia.com/shares/1/comments/1/page/2
I am pretty sure you get the idea.
p.s. if you will provide your API to a brand new clients, who don't know anything about it, then first one is also more understandable but, i suggest you also have a API documentation which describes the parameters and the relevant poasible other calls as well. in this way your url formatting will be clearer and clients will not struggle to solve parameters in the url.
The first way is not only functional, but lets a human understand what the name/value pairs are. Sure you could go into configuration and string manipulation and make your URL look like the second example and still function, but from a readability pov and ease of function, the first one is best.
I have a question.
I have comment model, in which it has body column that users can type anything in there.
obviously user might type the url link to other website.
In my guess, I think it should be replaced with < a href > tag when it is being saved.
Is there any good gem or something to handle this kind of thing?
If you don't want to use a full-blown markdown parser (Redcarpet), use Rinku. It's super fast and safe. Do not use any regex based solutions as you would most likely open yourself to security risks.
text = "Hello! Check this out: https://github.com/vmg/rinku"
Rinku.auto_link(text, mode=:all, link_attr=nil, skip_tags=nil)
Produces:
=> "Hello! Check this out: https://github.com/vmg/rinku"
Preserving for posterity's sake, but I feel it's important to note that this is NOT a secure way to solve the problem. Unless you want to figure out all the security implications for yourself, don't follow this advice. Jiří Pospíšil's answer is better. =D
You don't really need a gem to do that (I personally try to avoid gems for something so simple). Write a regular expression that is reasonably reliable for your purposes, and then use something like
input.gsub(regex, 'some text')
to convert the links into their html equivalent. Note that you'll need to use raw to display the results of this, otherwise rails will escape the output for you. This also means users will be able to put other arbitrary markup in, unless you escape it as it goes into the database. Make sure you do that.
Alternately, you could do the same thing as you display it, with slightly different considerations/steps necessary.
Suppose I have this code:
(handler-case (read ...)
(parse-error (condition)
(format t "What text was I reading last to get this error? ~s~&"
(how-to-get-this-text? condition))))
I can only see the parse-namestring accessors, but it gives the message of the error, not the text it was parsing.
EDIT
In my case the problem is less generic, so an alternative solution not involving the entire string that failed to parse can be good too.
Imagine this example code I'm trying to parse:
prefix(perhaps (nested (symbolic)) expressions))suffix
In some cases I need to stop on "suffix" and in others, I need to continue, the suffix itself has no other meaning but just being an indicator of the action the parser should take next.
READ parses from a stream, not a string. The s-expression can be arbitrarily long. Should READ keep a string of what's been read?
What you might need is a special stream. In standard Common Lisp there is no mechanism for user defined streams. But in real life every implementation has such extensible streams. See for example 'gray streams'.
http://www.sbcl.org/1.0/manual/Gray-Streams.html
There's no standard function to do it. You might be able to brute-force something with read-from-string, but whatever you do, it will require some extra work.
it's my first post here :)
I'm having some difficulties with dealing with urls and parameters. I've gone through the router class api documentation over and over again and found nothing useful.
First of all, I'd like to know if there is any 'universal' format in CakePHP(1.3) for handling urls. I'm currently handling all my urls as simple arrays(in the format that Router::url and $html->link accepts) and it's easy as long as I only need to pass them as arguments to cake's own methods. It usually gets tricky if I need something else.
Mainly I'm having problems with converting string urls to the basic array format.
Let's say I want to convert $arrayUrl to string and than again into url:
$arrayUrl=array('controller'=>'SomeController','action'=>'someAction','someValue');
$url=Router::url($arrayUrl); //$url is now '/path/to/site/someController/someAction/someValue'
$url=Router::normalize($url); //remove '/path/to/site'
$parsed=Router::parse($url); /*$parsed is now
Array(
[controller] => someController
[action] => someAction
[named] => Array()
[pass] => Array([0] => someValue)
[plugin] =>
) */
That seems an awful lot of code to do something as simple as to convert between 2 core formats. Also, note that $parsed is still not in the same as $arrayUrl. Of course I could tweak $parsed manually and actually I've done that a few times as a quick patch but I'd like to get to the bottom of this.
I also noticed that when using prefix routing, $this->params in controller has the prefix embedded in the action(i.e. [action] => 'admin_edit') and the result of Router::parse() does not. Both of course have the prefix in it's own key.
To summarize, how do I convert an url between any of these 3(or 4, if you include the prefix thing) mentioned formats the right way?
Of course it would be easy to hack my way through this, but I'd still like to believe that cake is being developed by a bunch of people who have a lot more experience and insight than me, so I'm guessing there's a good reason for this "perceived misbehavior".
I've tried to present my problem as good as I can, but due to my rusty english skills, I had to take a few detours :) I'll explain more if needed.
The "official" format for Cake URLs should be the array notation array('controller' => 'foo', 'action' => 'bar', 'baz', 'admin' => true). Whenever you write URLs, you should use this format. The Router class will translate those to either strings (/admin/foo/bar/baz) or information needed for the Dispatcher (array('named' => array(), 'pass' => array(), …)), depending on where the URL is used.
You should think of it in terms of which controller action you want to invoke. URLs (as strings) are only a necessary evil to accomplish this in a web context. There shouldn't be any need for you to use the Dispatcher format. You should also not use the string notation when specifying URLs, since these can't be reverse-routed if you ever want to change your URL scheme.
Maybe you could explain with an example why you need to convert these three forms from one to the other?
Closed. This question is opinion-based. It is not currently accepting answers.
Closed 8 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
I have a function, parseQuery, that parses a SQL query into an abstract representation of that query.
I'm about to write a function that takes an abstract representation of a query and returns a SQL query string.
What should I call the second function?
I think the verb you want is 'compose'.
The opposite of parse is serialize
In compiler terminology, the opposite is "unparse". Specifically, parsing turns a stream of tokens into abstract syntax trees, while unparsing turns abstract syntax trees into a stream of tokens.
Compose? When parsing a query you break it into its constituent parts (tokens, etc.), the reverse would be composing the parts into a string query.
To complement your existing naming, composeQuery looks best.
But in the general case, the opposite of parse is ǝsɹɐd
I would use one of these:
ToString()
ToSQL()
Render()
I think "serialize" is probably the word you want. It means to produce a textual representation of data that can be exported (and imported) from the program.
The antonym of 'analyze' is 'synthesize'.
ToQueryString()
Definitely Render.
I would call it constructQuery.
generate or emit, possibly.
Just to add some stuff.
Surely parse is a two way word.
You can parse an abstract into a query.
You can parse a query into an abstract.
The question should be, what do you name the latter part of the method, and because in this instance you're parsing an abstract to make a query you'd call it parseAbstract.
To answer the question, parsing has no opposite.
generateQuery, possibly? createQuery?
Take your pick
Generate
Dump
Serialize
Emit
They each have slightly different connotations.
Maybe prettyPrintQuery?
compose, construct, generate, render,condense, reduce, toSQL, toString depending on the nature of the class and its related operators
A traditional compiler has two parts: a parser and a code generator.
So you could call it "Generate". Of course, it's a little bit different here because the compiler isn't writing source code. (unless it's a precompiler).
Possibly Format(). or ToSQL() in your instance?
unParse()? Just kidding, I would go with toQueryString()
flatten?
The parsed query object perhaps represents a condition hierarchy, which you are "flattening" back into a 1 dimensional string.
But given that you're going from object to string, really just use toString or toSQL() or something like that. Besides, if you designed it well and are using the right app, you can rename it later and just stick stuff in the comments on what it does.
I'd say serialize and deserialize, instead of parse and ...
I would go for ToString(), since you can usually chain-nest them (opposite functions, that let you pass from Class1 to Class2 and vice-versa)
DateTime.Parse( DateTime.Parse( myDate.ToString() ).ToString() );
Serialize() looks like a nice choice, but it already has an opposite in Deserialize().
In your specific scenario, as other pointed out, ToSql() is another good choice.
I'd use render
> a = 'html': { 'head': {'title': 'My Page'}, 'body': { 'h1': 'Hello World', 'p': 'This is a Paragraph' } }
> b = render(a)
> console.log(b)
<html>
<head>
<title>My Page</title>
</head>
<body>
<h1>Hello World</h1>
<p>This is a Paragraph</p>
</body>
</html>
Which is IMHO, the opposite to parse()
> c = parse(b)
{ 'html': {
'head': {
'title': 'My Page'
}
'body': {
'h1': 'Hello World',
'p': 'This is a Paragraph'
}
}
+1 for Generate, but tack on what you're generating, i.e. GenerateSQL()
I voted for 'compose' but if you don't like that I would also suggest 'build'
What about asSQL() or even more asQuery()?
INHO Serialize, synthesize are good options. Also, as you have named parseQuery, i will go with codeQuery
I usually use "parse" as a conversion method and, therefore, i can't find a opposite word for "convert". (you can't "deconvert" something, as "unconvert" is a type of conversion itself).
thinking this way, the best solution (for me) is having two "parse" methods that receive different arguments. Example (Java):
public class FooBarParser{
public Foo parse(Bar bar);
public Bar parse(Foo foo);
}
deparse
Deparse is to parse, as:
decompile is to compile
decompose is to compose
deserialize is to serialize
degroovy is to groovy :) ;)
Parsing / deparsing is not change of structure, but conversion. Precise conversion between equivalent text and abstract-syntax-tree formats, maintaining all relationships & structure.
"Compose" means change of structure, so is not quite right. It suggests combining from separate independent parts (usually for the first time). Just as "decompose" suggests splitting into independent parts. They change form, not just format.
A quick search show's the term's used within:
Perl: http://perldoc.perl.org/B/Deparse.html
R: http://www.hep.by/gnu/r-patched/r-lang/R-lang_98.html
Common Lisp: http://www.clisp.org/impnotes/dffi.html#c-type-parse
PostgreSQL: http://doxygen.postgresql.org/deparse_8c.html
Eclipse: http://www.eclipse.org/forums/index.php/t/201883/
Unix Korn Shell: http://www.sourcecodebrowser.com/ksh/93tplus-p/deparse_8c.html