code reader wrote:MODx is proprietary (and ugly) format, that is meant to be used by humans, and is not friendly. it is ridiculously difficult to create, and not at all friendly to apply.
eviL3 wrote:I'd prefer to see these kind of actions in a separate file instead of mixing file changes and db changes.
We're talking about phpBB here so I don't see how patches being universal has any relevance. MODX has been around for over 2 years now so it could be argued that for phpBB, MODX is universal now since all MODs use it. If the point here is that it would be nice to generate a diff file instead of MODX or in conjunction with MODX and have the MOD installer handle that then that might be something to look into.nn- wrote:You realize of course that patches are universally useful while modx is phpbb (version) specific, right?
eviL3 wrote:IMO the code base of AutoMOD needs to be cleaned up. There needs to be better separation of concerns, less dependencies between the components. The MODX parser should use SimpleXML and XPath. There should be an API that can be used to install MODs programatically without having to load the whole phpBB environment with $template, trigger_error, etc.
Since this is a new addition to phpBB, there's a lot you can do with it. You can use dependency injection (passing information into classes instead of depending on globals).
You can use Exceptions instead of trigger_error, which means you don't have to worry that trigger_error will mess up your CLI output.
The file writing API is frankly a bit of a mess. Since there is a proper storage abstraction planned for 3.1, it may be possible to use that too for FTP, SFTP, etc.
There has already been some work on a CLI for 3.1
nn' wrote:I would like a facility to convert modx files to patch files and sql files.
code reader wrote:recently we switched to git. it is very reasonable to assume that every MOD developer has a full repo of the code.
nn- wrote:A patch with colored additions/removals, configurable amount of context, line numbers and ability to view new and old version of the file is very readable.
If you, the person reading this, consider patch files unreadable I suggest reading some diffs in trac.
imkingdavid wrote:I just think that having to first apply all the code changes with one program and then apply the sql with another is too much. Personally it isn't too big of a deal, but I think that the majority of admins would appreciate a more single-step approach. So if it is split into multiple files I think that the other file should still be run by AutoMOD to decrease the amount of steps required.
nn- wrote:Even if patch can't express inline finds, at the moment of installation automod locates the lines it's going to modify and alter them. If in fact modx inline finds cannot be translated to patch hunks using modx information only, then patch generation is actually domain of automod as opposed to modx tools contrary to what was stated earlier.
imkingdavid wrote:I don't mind having it in separate files for clarity and such, I just think that having to first apply all the code changes with one program and then apply the sql with another is too much.
A_Jelly_Doughnut wrote:Before I could fully comment, I'd need more information on what exactly will be implemented as this "storage abstraction."
A_Jelly_Doughnut wrote:First I've heard about this (phpBB 3.1 CLI). Someone care to elaborate?
eviL3 wrote:A_Jelly_Doughnut wrote:Before I could fully comment, I'd need more information on what exactly will be implemented as this "storage abstraction."
Henry mentioned it would be similar to cache. I guess would be something like a watered down filesystem. So you have ability to write resource, read resource, check if resource exists. Perhaps even list items and have namespacing (eg. directories). And also provide a public link in case of avatars, attachments.
Users browsing this forum: Exabot [Bot] and 13 guests