When JSON came out, it came with a nice dedicated web-page. They summarized the ggrammar on a single page. They explained how easy it is to use JSON (natively) in JS. Then they provided a miriad of libraries for other languages.
Now NEON is available in PHP. I am new to PHP, but I lack to see it's usefulness (except it tries to be pretty, for the price of ambiguity and white-space problems).
Is there any reason I shouldn't cut out all NEON stuff and replace it with simple JSON?
I think you misunderstand some things.
NEON is default configuration file for Nette framework, it's nothing like that will be replacing JSON in PHP for ever.
NEON is 100% capable of replacing JSON object, but it's mainly targeted for configuration files, which will be modified by people. At same time it's a powerful alternative for YAML which is also great configuration file format for humans used for example in Symfony FW.
There are no problem with spaces/tabs in real at all, you just must use one of them - that's only strict not bad. Because good code starts with consistency. There are plenty ways of doing things, but in one project, you should have things unified.
JSON is cross-platform compatible format which is surely has place in projects. Mostly in generated files. But it's really clumsy and ugly for files which are directly changed by developer. NEON/YAML do this thing 1000x better, and if you does not get it that value added to configuration files, then you probably doesn't work enough with configuration files.
In Nette, you can use configuration in many other file types - even in json. But if you new in PHP as you said, don't do it. Nette and Symfony FWs weren't use this formats for nothing. It is has added value.
Neon is maybe more readable than json, but as you said there are some problems with white-space / tab. But many IDEs (NetBeans, PhpStorm...) support it, so you can use auto-format.
Related
I did some search about localization files, see that we can use .po file or gettext but, is there any tutorial or sample of a unique solution that will work both in javascript and in php.
I want to only maintain one localization file per language that will work with both JS and PHP languages.
Would appreciates if someone can point me to some links or samples...
I found that it is typically a sign of a questionable design when translatable text is coded inside JS functions. JS is meant to implement logic, not content. The content should be provided by PHP (typically by using a templating engine) and should be used by JS. That way you only need a localization solution for PHP.
If (exceptions always occur) you really need to translate a phrase inside a JS routine you use an ajax call to fetch the translation. This also simplifies the access to the dictionary holding the translation tokens since it is again done by PHP. The dictionary can be kept in a single place.
Yep, there is. I've successfully used gettext.js a while ago, which is operating on .json or .po files. This way, you only have to maintain one translation source. The webpage I've used this for is located here so you can check out how I've did it. Good luck!
First, try to avoid gettext if you can. It's popular and stable, but it puts some burden on the translations maintenance: you will need to change the source strings, and when this happens, gettext needs to update all the message keys, and this may mess up the existing translations. An approach with constant message keys is much easier to maintain in the long run - you will need to remember to delete the keys you don't use any more, but it's a very small burden.
You can use the same translations storage format for PHP and JavaScript. If you use a key-based approach, as I suggest, it will probably be some JSON-based format. JSON is easily accessible in both PHP and JavaScript.
There are several ready-made JavaScript libraries for JSON-based internationalization. I happen to be a developer of one such library: https://github.com/wikimedia/jquery.i18n . It should be reasonably easy to adapt it to PHP.
Is there a native PHP wbxml API that can be used platform-independently? Perhaps a loadable module?
I have seen the pecl implementations but I have not been able to successfully work with the builds on win32 platforms.
I am not an expert, but what I found out there numbered two options, essentially.
One, the pecl library that you are having trouble with.
Two, I found WBXML encoder and decoder classes in Horde of all places. They might give you a starting point, and since they are open source, they might meet your needs quite nicely. Here is a link where I found them.
http://phpxref.com/xref/horde/lib/XML/WBXML/index.html
I don't know a huge amount about WBXML, but from what I can gather it's a binary-formatted XML file. I suppose at the simplest you could use the XML modules such as simpleXML to generate your XML document, output it as a string and then use PHP's built in file handling functions (fopen, fwrite, etc) to dump the string as binary data to a file. To reverse the process load the file as a string and have SimpleXML parse it.
However, without knowing the specific details of the WBXML format, I'm sure there's more to it tan that. You'd also have to implement the necessary code yourself, but as you could implement it in PHP itself that should make cross-platform portability a bit simpler to accomplish.
Not really an answer as such, I'm afraid, but I hope it gets you going in the right direction.
I'm writing a WordPress plugin to create an eBook from a selected category in most major eBook formats. I would like to support MobiPocket since that's the format used by the Kindle but I'm not sure how to go about it. From what I've read .mobi files are actually Palm Resource Databases (PRC) but I haven't been able to find a PHP class to work with these.
I thought about using exec along with KindleGen but that would be undesirable as it would complicate initial setup. I've also thought about hosting a web service somewhere and using XML-RPC to accomplish this but that also complicates things.
My question is: is there a PHP class/library (PHP-only preferred) that can work with PRC or even better, a class that specialises in creating MobiPocket ebooks? (needs to be open source since I'm releasing under the GPL)
I've tried searching but haven't been able to find anything.
I don't know whether you're still looking for this PHP library, but just in case: https://github.com/raiju/phpMobi. This is a library that creates mobi files from html files.
It's should still be seen as an experimental version, but it should work without a problem for basic document with a few images.
Unfortunately not; however, the binary compiled format is an open specification available at:
http://www.mobipocket.com/dev/article.asp?BaseFolder=prcgen
The only direct way of transforming the uncompiled format is using the native XML functionality of PHP to create them and then invoking a compiler with exec, which I understand you don't want to do. If you go with this route, the link above also has details about this XML format.
You might want to try the mobiperl tools,
https://dev.mobileread.com/trac/mobiperl/wiki
Please note I haven't tested them yet. But they have been
around since at least 2007 so they should work well by now.
google "Mobiperl - Perl tools for handling MobiPocket files" to
find a thread on mobileread board discussing it. As a new
poster I can't put 2 hyperlinks into my reply.
Another tool I have recently found (but not yet tested), is: http://www.phpclasses.org/package/8173-PHP-Generate-Kindle-ebook-file-in-mobi-format.html#files
It is based upon KindleGen, and looks pretty straight forward to implement.
I am going to start working on a website that has already been built by someone else.
The main script was bought and then adjusted by the lead programmer. The lead has left and I am the only programmer.
Never met the lead and there are no papers, documentation or comments in the code to help me out, also there are many functions with single letter names. There are also parts of the code that are all compressed in one line (like where there should be 200 lines there is one).
There are a few hundred files.
My questions are:
Does anyone have any advice on how to understand this system?
Has anyone had any similar experiences?
Does anyone have a quick way of decompressing the lines?
Please help me out here. This is my first big break and I really want this to work out well.
Thanks
EDIT:
On regards to the question:
- Does anyone have a quick way of decompressing the lines?
I just used notepad++ (extended replace) and netbeans (the format option) to change a file from 1696 lines to 5584!!
This is going to be a loooonnngggg project
For reformatting the source, try this online pretty-printer: http://www.prettyprinter.de/
For understanding the HTML and CSS, use Firebug.
For understanding the PHP code, step through it in a debugger. (I can't personally recommend a PHP debugger, but I've heard good things about Komodo.)
Start by checking the whole thing into source control, if you haven't already, and then as you work out what the various functions and variables do, rename them to something sensible and check in your changes.
If you can cobble together some rough regression tests (eg. with Selenium) before you start then you can be reasonably sure you aren't breaking anything as you go.
Ouch! I feel your pain!
A few things to get started:
If you're not using source control, don't do anything else until you get that set up. As you hack away at the files, you need to be able to revert to previous, presumably-working versions. Which source-control system you use isn't as important as using one. Subversion is easy and widely used.
Get an editor with a good PHP syntax highlighter and code folder. Which one is largely down to platform and personal taste; I like JEdit and Notepad++. These will help you navigate the code within a page. JEdit's folder is the best around. Notepad++ has a cool feature that when you highlight a word it highlights the other occurrences in the same file, so you can easily see e.g. where a tag begins, or where a variable is used.
Unwind those long lines by search-and-replace ';' with ';\n' -- at least you'll get every statement on a line of its own. The pretty-printer mentioned above will do the same plus indent. But I find that going in and indenting the code manually is a nice way to start to get familiar with it.
Analyze the website's major use cases and trace each one. If you're a front-end guy, this might be easier if you start from the front-end and work your way back to the DB; if you're a back-end guy, start with the DB and see what talks to it, and then how that's used to render pages -- either way works. Use FireBug in Firefox to inspect e.g. forms to see what names the fields take and what page they post to. Look at the PHP page to see what happens next. Use some echo() statements to print out the values of variables at various places. Finally, crack open the DB and get familiar with its schema.
Lather, rinse, repeat.
Good luck!
Could you get a copy of the original script version which was bought? It might be that that is documented. You could then use a comparison tool like Beyond Compare in order to extract any modifications that have been made.
If the functions names are only one letter it could be that the code is encoded with some kind of tool (I think Zend had a tool like that - Zend Encoder?) so that people cannot copy it. You should try to find an unencoded version, if there is one because that would save a lot of time.
I have normally hand written xml like this:
<tag><?= $value ?></tag>
Having found tools such as simpleXML, should I be using those instead? What's the advantage of doing it using a tool like that?
Good XML tools will ensure that the resulting XML file properly validates against the DTD you are using.
Good XML tools also save a bunch of repetitive typing of tags.
If you're dealing with a small bit of XML, there's little harm in doing it by hand (as long as you can avoid typos). However, with larger documents you're frequently better off using an editor, which can validate your doc against the schema and protect against typos.
You could use the DOM extenstion which can be quite cumbersome to code against. My personal opinion is that the most effective way to write XML documents from ground up is the XMLWriter extension that comes with PHP and is enabled by default in recent versions.
$w=new XMLWriter();
$w->openMemory();
$w->startDocument('1.0','UTF-8');
$w->startElement("root");
$w->writeAttribute("ah", "OK");
$w->text('Wow, it works!');
$w->endElement();
echo htmlentities($w->outputMemory(true));
using a good XML generator will greatly reduce potential errors due to fat-fingering, lapse of attention, or whatever other human frailty. there are several different levels of machine assistance to choose from, however:
at the very least, use a programmer's text editor that does syntax highlighting and auto-indentation. just noticing that your text is a different color than you expect, or not lining up the way you expect, can tip you off to a typo you might otherwise have missed.
better yet, take a step back and write the XML as a data structure of whatever language you prefer, than convert that data structure to XML. Perl gives you modules such as the lightweight XML::Simple for small jobs or the heftier XML::Generator; using XML::Simple is just a matter of arranging your content into a standard Perl hash of hashes and running it through the appropriate method.
-steve
Producing XML via any sort of string manipulation opens the door for bugs to get into your code. The extremely simple example you posted, for instance, won't produce well-formed XML if $value contains an ampersand.
There aren't a lot of edge cases in XML, but there are enough that it's a waste of time to write your own code to handle them. (And if you don't handle them, your code will unexpectedly fail someday. Nobody wants that.) Any good XML tool will automatically handle those cases.
Use the generator.
The advantage of using a generator is you have consistent markup and don't run the risk of fat-fingering a bracket or quote, or forgetting to encode something. This is crucial because these mistakes will not be found until runtime, unless you have significant tests to ensure otherwise.
hand writing isn't always the best practice, because in large XML ou can write wrong tags and can be difficult to find the reason of an error. So I suggest to use XMl parsers to create XML files.
Speed may be an issue... handwritten can be a lot faster.
The XML tools in eclipse are really useful too. Just create a new xml schema and document, and you can easily use most of the graphical tools. I do like to point out that a prior understanding of how schemas work will be of use.
Always use a tool of some kind. XML can be very complex, I know that the PHP guys are used to working with hackey little stuff, but its a huge code smell in the .NET world if someone doesn't use System.XML for creating XML.