Bringing Evo back to life again

• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #151, 14 years, 6 months ago

  Speaking of Evo improvements, I've just made a lot of minor improvements and synched them to my GitHub repository. Now if I can only figure out the proper way to make pull requests I'll see if Stefanie wants my changes.
  
  https://github.com/sottwell/evo-dev
  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 #152, 14 years, 6 months ago

  I think you have to fork it form my repository (https://github.com/sjstoelting/evolution), than you can add a pull on that repository.
  Please give me some text to see, what the changes do without sniffing through the code first.
  Gone away and found a better place to stay
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #153, 14 years, 6 months ago

  That was just ugly. I'll attach a text file instead.
  
  Now I'm confused; when I fork it I get the whole thing with 10 branches. What am I supposed to do with that? [ed. note: sottwell last edited this post 14 years, 5 months ago.]
  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 #154, 14 years, 5 months ago

  Thank you Susan, but I didn't mean here in the forum, just as comment on pull in github
  
  But it's OK, now I know what it is about.
  Gone away and found a better place to stay
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #155, 14 years, 5 months ago

  I removed everything, trying to get a fork... I guess I have to make my own branch on my fork?
  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 #156, 14 years, 5 months ago

  No, you just have to checkout the branch 1.1.dev.
  
  

  git checkout 1.1.dev

  
  
  I'm using 1.1.dev.sjs for my own changes until they are stable, then I'll branch them into 1.1.dev. This way one can see, that I'm working and share my code.
  
  If you are working on something, just create a new branch:
  

  git branch 1.1.dev.so

  
  Later on merge the branch into the 1.1.dev branch:
  

  git checkout 1.1.dev
  git merge 1.1.dev.so
  

  
  Now you can file a pull request on github with 1.1.dev.
  
  I love branches in Git, I hated them in Subversion.
  Gone away and found a better place to stay
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #157, 14 years, 5 months ago

  Well, I can't make heads nor tails of this. I'll have to try again later.
  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 #158, 14 years, 5 months ago

  The work-flow with creating your own branches (I used so as shortcut for your name) is just for further development, because it makes live easier. This way your are also using github as backup for your local changes, if you push them.
  
  The changes you mentioned above can be done directly in 1.1.dev.
  Gone away and found a better place to stay
• • ☆ A M B ☆
  • 24,524 Posts
  sottwell Reply #159, 14 years, 5 months ago

  Ok. I got it forked, cloned, your fork set as my "upstream" and my own branch in my fork.
  
  I guess I'll just have to take it from this point and see what I can break!
  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
• • MODX Staff
  • 10,725 Posts
  opengeek Reply #160, 14 years, 5 months ago

  Quote from: Stefanie at Mar 30, 2012, 08:49 AM

  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.

  
  I think you may be missing some key points as to why Revo has adopted certain object-oriented programming patterns...
  
  Query building in xPDO is very fast and is certainly not the bottleneck your are experiencing. And xPDO is designed for allowing quick CRUD out of the gate while providing room to optimize queries per platform, including hand crafting them—and being able to automatically cache the results of those queries to just about any cache system available. And automatically join related tables for you. There are a lot of benefits in terms of maintaining code and being able to quickly prototype and extend a data model. It even separates a domain classes from the engine-specific table classes, which is an important design pattern allowing separation of business logic and database logic. To me it's the best of both worlds; simple OO CRUD with access to direct SQL when and where I need it.
  
  The current bottlenecks are in the amount of code in the core classes; definitely some code that can be reduced as the need to support older version of PHP 5 fade away. But again, there is a scalability vs. baseline performance curve that is not being considered here at all in this discussion of direct database vs. object/relational access to the database. How are you going to support clustered database environments with one node for writing and many for reading? xPDO already handles this for you. How are you going to port this to other db's? xPDO provides an easy path for that.
  
  Regardless, I'd really like to find a way to convince you not to give up hope in Revo/xPDO, or go off and attempt to re-architect another next-generation CMS from the same baseline again. Why not cooperate on improvements to the newer codebase to address the issues preventing you from adopting it? Maybe I am naive, but I think with a different manager UX that is more easily customizable (like Evo's used to be) and some code-reduction in the core to address some baseline performance issues, we would all be back on the same page trying to achieve the same goal as a community.
  Jason Coward
  Chief Architect @ MODX
  http://www.jasoncoward.com | http://twitter.com/drumshaman | https://github.com/opengeek

This discussion is closed to further replies. Keep calm and carry on.