>
> redmine and phabricator developer-alike, saw them using in other projects,
> phab is probably little slower, maybe it depends on hosting.
This phabricator website is very funny. "Have terrible software? Keep track
of all the defects and problems with your awful code using Maniphest."
"Bold text wins arguments!", "Companies probably using Phabricator".
Oeai, this Phabricator looks very neat thank you for the link.
Back on topic, you are right, we could put a line in the sand and leave the
old and link to it as an option D. I tend to believe this is worst-case
scenario.
On Mon, Apr 28, 2014 at 1:33 AM, Jonathan Aquilina <eagles051...@gmail.com>
wrote:
> @tres, That is the whole point of silverstripe. whats seen by the end user
> is what ever you really want it to be. The silver stripe back end is there
> to make life easier. If you look at the pages in the back end they do Have
> an editor to be able to work with custom code.
>
No, the point of Silverstripe and all other CMSs is NEVER to just place
stand-alone PHP code inside a CMS. CMSs have their own layouts,
authentication and navigation. They are a framework and you code within
the design of that framework. They also have their own database bindings.
If you try to re-use code, we'll have yet another Frankenstein on our
hands. :)
Option A is undoubtedly the most amount of work and frankly I don't think
anyone has the time or ambition to create it. If you are serious about
getting the LSP running on a new technology you may want to reconsider this
thought process.* The more CMS built-in functionality we use, the easier
this will be to maintain and upgrade. * Once you start spinning your own
modules you're getting into CMS plugin maintenance. Although the idea of
this is noble, I think you are grossly underestimating the amount of work
involved.
Here's a 2009 video with someone writing their own module. The code he is
typing is what you we would need to learn and know and the custom code
would be its own repository we would have to manage. Mind you, these
modules are still be at the mercy of the silverstripe database bindings.
It is very unlikely any of the old LSP code will be reusable in Option A.
https://www.youtube.com/watch?v=E1msUj9CwRg
But talking about this is a wasteful exercise at this point. Start
creating the custom content types and start creating the fields we need.
The CMS is already designed with scalability in mind. Once you get the
content type created we can try to build out the constraints and views that
replicate the current functionality. When we hit a roadblock, then we
decide if its better to code or use a 3rd party module. At no point should
we be staring at the old code for these evaluation exercises.
------------------------------------------------------------------------------
"Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos. Get
unparalleled scalability from the best Selenium testing platform available.
Simple to use. Nothing to install. Get started now for free."
http://p.sf.net/sfu/SauceLabs
_______________________________________________
LMMS-devel mailing list
LMMS-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lmms-devel
