Bringing Evo back to life again

☆ A M B ☆
1,231 Posts

yama Reply #291, 14 years, 5 months ago

https://github.com/sjstoelting/evolution/commit/8143b4fc3993f5c572aa0b1625e1df519d2d3e22
I think that it is unnecessary.
Even if there are these functions, the function of Etomite cannot necessarily be used as it is.
(I actually tried some)

222 Posts

Stefanie Reply #292, 14 years, 5 months ago

Of course, I would write unit tests and correct them, until they do what one expects, if the decision is to leave them in and use them.

Gone away and found a better place to stay

898 Posts

chucktrukk Reply #293, 14 years, 5 months ago

I have never seen any of those methods used. I feel those would be safe to either remove or make private.

I like the idea of privatizing as a way to test deprecation. I think these are so old and un-used, I don't think anyone would miss them. I've never even seen them.

Chuck the Trukk
ProWebscape.com :: Nashville-WebDesign.com
- - - - - - - -
What are TV's? Here's some info below.
http://modxcms.com/forums/index.php/topic,21081.msg159009.html#msg1590091
http://modxcms.com/forums/index.php/topic,14957.msg97008.html#msg97008

222 Posts

Stefanie Reply #294, 14 years, 5 months ago

In the blog at http://modx.com/blog/2012/04/19/bringing-evolution-development-back-to-life/ I missed the way, how the MODX team want to integrate the community. Therefore I made a comment, to ask about how they want to go on.

I've done very granular commits for adding visibility (private, public), PHPDoc tags, and cleaning the code. My question is now, does the MODX team want a ticket and pull for every commit or one ticket for the hole bunch?

I changed functions, to only have one exit (return). The other way is easier, but is bad coding style, because when one works on such a function, it might happen, that the change is never triggered at all.

There where also some nice if constructs, that should not be used at all:

 if ($numEvents > 0)
            for ($i= 0; $i < $numEvents; $i++) { // start for loop
                $pluginName= $el[$i];
                $pluginName = stripslashes($pluginName);
                //....
            }

Changed to

if ($numEvents > 0) {
    for ($i= 0; $i < $numEvents; $i++) { // start for loop
        $pluginName= $el[$i];
        $pluginName = stripslashes($pluginName);
        //....
      }
}

[ed. note: Stefanie last edited this post 14 years, 5 months ago.]

Gone away and found a better place to stay

172 Posts

TimGS Reply #295, 14 years, 5 months ago

Hi,

This is a good thread to see!

I've been only an occasional visitor to these forums since Revolution became the primary version of MODx, and have been using another CMS (Silverstripe) when it has been my decision to do so. I have coded for Revo but with existing clients who themselves have chosen to switch to Revo.

Of the two MODx versions, Revo is the one being pushed the most, and as such the future of Evo appears to me to be shakey. I prefer Evo myself, and will continue to maintain my own existing Evo sites, but I have hesitated to recommend to clients that they use a CMS with an uncertain future. I know at this point someone is going to say how Evo will continue to be supported - fine, say it - but I am not confident in this and as such I cannot honestly recommend it to clients as things stand.

As such, I hope this fledgling project gets out of its nest. As I see it the primary issue is not technical, but political.

Firstly, does this project live with MODx or independently? Maybe it would be best to let MODx get on with the Revolution whilst Evo - or at least a fork - goes its own way.

Secondly, as has already been said, we need people who can manage and coordinate as well as understand the technical issues and conflicts that may exist between different contributions. An assorted collection of good but disparate technical solutions is unlikely to succeed.

Thirdly we need a way of ensuring the 'community' has confidence in the decision making process and is part of it. If this doesn't happen people will not use it. I have had a varied experience of using open source projects and the variation in how seriously 'teams' take reported problems is stunning - it varies from the blasé, to the extent of security issues being dismissed, to the exceptionally conscientious. I'm inclined to stick to using projects run by the latter.

These three issues are probably in ascending order of trickiness!

I'm keen to contribute to the technical side of things, am familiar with the API and parts of the core, and have been looking into the nested snippet issue that has been a persistent problem. I hope to have a solution soon, but this is an aside - before we plunge into technical fixes we need realise that the crucial issues are - like it or not - political!

-- Tim.

☆ A M B ☆
1,231 Posts

yama Reply #296, 14 years, 5 months ago

Quote from: TimGS at Apr 30, 2012, 02:51 PM

and have been looking into the nested snippet issue that has been a persistent problem

https://github.com/sjstoelting/evolution/commit/1ebf1f611b6acefe1be48b3867fb9c772d0aa2db
It is solvable.

172 Posts

TimGS Reply #297, 14 years, 5 months ago

Quote from: yama at Apr 30, 2012, 04:43 PM

Quote from: TimGS at Apr 30, 2012, 02:51 PM
and have been looking into the nested snippet issue that has been a persistent problem

https://github.com/sjstoelting/evolution/commit/1ebf1f611b6acefe1be48b3867fb9c772d0aa2db
It is solvable.

The problem is elsewhere to evalSnippet. evalSnippets is more of an issue. There is also a further minor but possibly more complex to solve issue if all combinations of cached/uncached snippets are to be cached/uncached correctly.

thanks,
-- Tim.

Edit: Pull request made https://github.com/sjstoelting/evolution/pull/12 . My suggestion as to feedback is to comment on the technicalities there. There are more important and fundamental issues to be discussed in this more general thread. Its not actually a big change, just one line in document.parser.inc.php. Perhaps further testing will produce some issues which make life more complex, but for now:

    function evalSnippets($documentSource) {
	preg_match_all('~\[\[((.(?!\[[[!]))*?)\]\]~ms', $documentSource, $matches); // (TimGS)

[ed. note: TimGS last edited this post 14 years, 5 months ago.]

☆ A M B ☆
1,231 Posts

yama Reply #298, 14 years, 4 months ago

The pilot edition was completed.

http://code.google.com/p/modx-ja/downloads/detail?name=107.zip

http://modx.jp/news/820.html

222 Posts

Stefanie Reply #299, 14 years, 4 months ago

A great and warm applause for yama and the Japanese community

I've pulled the commits, they are available on Github at https://github.com/sjstoelting/evolution/tree/1.1.dev.japanese.

I'll merge the Japanese and the dev branch today in the evening, there are some merge conflicts to solve.

Gone away and found a better place to stay

172 Posts

TimGS Reply #300, 14 years, 4 months ago

The test showed, that ezŚQL is the fastest of all mentioned database classes.

I've had a quick look at ezSQL.

I have a concern about the way it pulls in complete data sets whether you need them or not. The query() method appears to populate an array with all result rows for that query. Now it is certainly best not write a query in the first place that fetches more data than you need, but if you need to process that data outside of the SQL before working out where to 'stop' then perhaps that could result in performance issues for large datasets, especially if the database is on a remote machine to the web server.

Development and documentation needs to make this clear, plus perhaps we should include methods that just fetch one result row at a time.

On a different note, well done to the Japanese coders!

-- Tim.