Bringing Evo back to life again

222 Posts

Stefanie Reply #141, 14 years, 6 months ago

There might be a TinyMCE in the new Evo, if someone will work on the editor, it is "only" a plugin. The old versions of Evo had FCKEditor as default.

As we here in this thread where all about switching to jQuery as JavaScript library, the next default editor should be based on jQuery.

Current status message
The work on the database classes are going on, I can establish a connection with ezSQL, but now there is a lot work on the SQL to do. For example it was not possible to connect to the database with backticks at start and the end of the name.

Currently I'm working on the document parser class.

Gone away and found a better place to stay

☆ A M B ☆
24,524 Posts

sottwell Reply #142, 14 years, 6 months ago

Upgrading the version of TinyMCE is very simple. Just download the latest version from MoxieCode, extract it and move the jscripts/tiny_mce folder to replace the old one in assets/plugins/tinymce/jscripts.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

☆ A M B ☆
872 Posts

lossendae Reply #143, 14 years, 6 months ago

Just passing by just to say how much i don't like ezSQL.

It's the same engine as in WP and for simple query it is relatively cool, but for more complex queries, it's simply horrendous to work with.
Plus wordpress uses a custom implementation of sprint_f to escape the values, which make the process even less likeable.

That being said, it does not prevent me to develop with WP, so it should not really bother me with evo as well i guess...

☆ A M B ☆
24,524 Posts

sottwell Reply #144, 14 years, 6 months ago

From research that I've done on the subject, any complex query is going to require horrendous amounts of work to build, either on the back-end or on the part of the programmer. The major problem with the libraries that support "simplified" complex query building is that invariably you'll want to do something that is not covered by the library's API and you'll end up with hand-coding the query anyway. And, of course, the second point is that these APIs are necessarily large and heavy, which is of questionable use in 99% of cases. So it comes down to a question of optimization. Carry an elephant gun everywhere you go to swat the mosquitoes with, just on the off chance you'll run into a rogue elephant, or carry a flyswatter and dig an elephant trap if there's a rogue in the neighborhood.

There's an interesting synopsis on the topic of database agnosticism here http://codex.wordpress.org/Using_Alternative_Databases

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org

222 Posts

Stefanie Reply #145, 14 years, 6 months ago

If you let your application build your queries as it is done with MVC frameworks like CakePHP or Symphony you don't have anything to do with queries. That's the good one.

On the other hand you run queries on the database, when you don't need the result in some cases, just because there are models included. Query optimization is the next thing, that doesn't happen. ORM wrapper take all fields of a record, even when only one field is needed.

In the end you have to buy hardware, to get performance into non performance applications. But yes, you had nothing to do with complex queries.

Gone away and found a better place to stay

MODX Staff
730 Posts

netProphET Reply #146, 14 years, 6 months ago

Quote from: Stefanie at Mar 29, 2012, 10:59 PM

ORM wrapper take all fields of a record, even when only one field is needed.

This is not true of xPDO; you can specify the fields to load.

Mike Schell
Lead Developer, MODX Cloud
Email: [email protected]
GitHub: https://github.com/netProphET/
Twitter: @mkschell

222 Posts

Stefanie Reply #147, 14 years, 6 months ago

Yes, that is true, but I wasn't talking about xPDO. But you have to code the cases, when you want less than all fields.
Why not in SQL to get all performance and features, a database can give to you?

PS.: You can do this also with CakePHP and Symphony, but I haven't seen much of this. Normally the models are included and that's it.

Gone away and found a better place to stay

4,149 Posts

splittingred Reply #148, 14 years, 6 months ago

Quote from: sottwell at Mar 29, 2012, 10:20 PM

From research that I've done on the subject, any complex query is going to require horrendous amounts of work to build, either on the back-end or on the part of the programmer. The major problem with the libraries that support "simplified" complex query building is that invariably you'll want to do something that is not covered by the library's API and you'll end up with hand-coding the query anyway. And, of course, the second point is that these APIs are necessarily large and heavy, which is of questionable use in 99% of cases. So it comes down to a question of optimization. Carry an elephant gun everywhere you go to swat the mosquitoes with, just on the off chance you'll run into a rogue elephant, or carry a flyswatter and dig an elephant trap if there's a rogue in the neighborhood.

This is why xPDO is superior; it has driver-specific classes that you can write methods for to run specific queries for various DB drivers, without having to run switch statements.

xPDO can also handle many edge cases with complex SQL statements via its nested array syntax and conditional prefixing in the xPDOQuery->where() command.

shaun mccormick | bigcommerce mgr of software engineering, former modx co-architect | github | splittingred.com

222 Posts

Stefanie Reply #149, 14 years, 6 months ago

Quote from: splittingred at Mar 30, 2012, 08:30 AM

Quote from: sottwell at Mar 29, 2012, 10:20 PM
From research that I've done on the subject, any complex query is going to require horrendous amounts of work to build, either on the back-end or on the part of the programmer. The major problem with the libraries that support "simplified" complex query building is that invariably you'll want to do something that is not covered by the library's API and you'll end up with hand-coding the query anyway. And, of course, the second point is that these APIs are necessarily large and heavy, which is of questionable use in 99% of cases. So it comes down to a question of optimization. Carry an elephant gun everywhere you go to swat the mosquitoes with, just on the off chance you'll run into a rogue elephant, or carry a flyswatter and dig an elephant trap if there's a rogue in the neighborhood.

This is why xPDO is superior; it has driver-specific classes that you can write methods for to run specific queries for various DB drivers, without having to run switch statements.

xPDO can also handle many edge cases with complex SQL statements via its nested array syntax and conditional prefixing in the xPDOQuery->where() command.

Yes, that is something that ORM are for. But you are using an interpreted language (PHP) for parsing and creating database queries.
You'll never be on the fast side with this constructs. Comparing C and/or Assembler compiled sources against interpreted languages, the interpreted language will loose the race. That means: The database takes it all.

You might come up a little bit using things like using HipHop, but then you have a complex build process. In addition HipHop does it only with MySQL and not all PHP commands are supported.
There will be an other player with compiled PHP, but it is not ready by now. The article on heise.de is only available in English, but Google Tranlate might help:
http://translate.google.com/translate?sl=de&tl=en&js=n&prev=_t&hl=en&ie=UTF-8&layout=2&eotf=1&u=http%3A%2F%2Fwww.heise.de%2Fnewsticker%2Fmeldung%2FFabric-Engine-bringt-JavaScript-auf-C-Niveau-1495054.html

My meaning is: Let the database do what databases are for.
And yes, this is more work on the development side, and yes you need people who know what they are doing on databases.

Gone away and found a better place to stay

☆ A M B ☆
24,524 Posts

sottwell Reply #150, 14 years, 6 months ago

This is exactly why I've dropped Revo altogether after several months of getting to know it well enough to give it a chance. Heavy and slow, not to mention rather fragile. For websites, I want light, quick and robust. If that means I have to do a little more of the heavy lifting myself in the rare cases where such heavy lifting is needed, so be it. Now I have more time to work on Evo improvements. It's simply a matter of personal preference.

Studying MODX in the desert - http://sottwell.com
Tips and Tricks from the MODX Forums and Slack Channels - http://modxcookbook.com
Join the Slack Community - http://modx.org