Modular refactoring possible?

[eluser]Tom Vogt[/eluser]
[quote author="TheFuzzy0ne" date="1241575325"]Hopefully this makes sense.[/quote]

It does. Thanks. I'll check some alternatives and maybe come back to this idea, which I see as the only feasable one at this time.

[eluser]Phil Sturgeon[/eluser]
Post is left in the $_POST variable and $_GET can be enabled via the instructions in this post.

$_SESSION can be accessed via OB_Session but you can still just use $_SESSION as normal if you have a session_start() somewhere in your application fairly early on.

As for models, you will want to make your own Model class that does absolutely nothing. That way when you include a model file it will not be trying to extend a non-existent class.

Not sure what you would have in your modules as things like Active Record and all other models/libraries would not be accessible via the model's $this.


My best suggestion for model/library access as you port over is a clever __autoload() which checks the model and library folders.

Instead of

Code:

$this->some_library->get();

do...

Code:

$some_library = new Some_library();
$some_library->get();

That way you dont need to worry about including the files and this is perfectly compatible with CI.

Basically you are avoiding some of CI's features just to get the app working in that environment, then you can modify and merge it in as you go.

This is possible, it is just going to be tricky.

[eluser]Thorpe Obazee[/eluser]
[quote author="Tom Vogt" date="1241562036"][quote author="Dam1an" date="1241554726"]I would personally recommend starting from the controllers, creating functios for each page, and then calling the code you execute in the current systen... you can then move from there[/quote]

Yeah, I was afraid of something like that. It would mean I have to setup 500 controllers. [/quote]

Woah. if you ever have 500 controllers, you'd need to check how the application is designed.

[eluser]Tom Vogt[/eluser]
[quote author="bargainph" date="1241615378"]Woah. if you ever have 500 controllers, you'd need to check how the application is designed.[/quote]

You're probably right. We have about 500 scripts now, which would translate into less than 500 controllers, more 500 methods within much less controllers.

[eluser]n0xie[/eluser]
The way I would do it:

If the current application has 1 entry point then it's pretty easy:

In your index.php:
1. check if the controller is available in /system/application/controllers by matching the url against the file system much in the same way Code Igniter does now (you could probably just hack it).
2. If so, run CI as normal.
3. If not, run the 'old' index.php code and execute the site 'old style'

This way you can start migrating/refactoring bits and pieces one by one (although if you have 500+ 'estimated' controllers you seriously should rethink your business logic imho).

The benefit is that you won't lose SEO rating since the old site is still there. When you have migrated certain parts you can use a 301 or 302 to the 'new' site so google won't penalize your 'broken links'.

If the application has different entry points I would replace them one by one by refactoring the entry points, again keeping both sites available (old and new) and rerouting the request either from your .htaccess or said entry point.

Then again it highly depends on how modular your original code base is. I would however advise you to read this article. Sometimes rebuilding from scratch isn't the best solution...

[eluser]TheFuzzy0ne[/eluser]
That's pretty much what I was getting at, only I would probably implement a system that not only checks the controllers first, but it would check in an array for any controller names, and if the requested controller name is in there, it will redirect to the old site. This means that you're users should never end up using a controller you're currently working on.

[eluser]n0xie[/eluser]
[quote author="TheFuzzy0ne" date="1241625565"]That's pretty much what I was getting at, only I would probably implement a system that not only checks the controllers first, but it would check in an array for any controller names, and if the requested controller name is in there, it will redirect to the old site. This means that you're users should never end up using a controller you're currently working on.[/quote]
Good idea. Although if you work with a SCM you'd probably only push 'finished' parts towards the 'live' website, so in theorie it shouldn't be necessary, but rather safe than sorry so I would definitely go with TheFuzzyOne's idea (I guess you'd call it a 'whitelist').

[eluser]Tom Vogt[/eluser]
[quote author="n0xie" date="1241620553"]The way I would do it:

If the current application has 1 entry point then it's pretty easy:

In your index.php:
1. check if the controller is available in /system/application/controllers by matching the url against the file system much in the same way Code Igniter does now (you could probably just hack it).
2. If so, run CI as normal.
3. If not, run the 'old' index.php code and execute the site 'old style'[/quote]


Yeah, problem being the old app doesn't follow the "one entry point" philosophy. If you call battlemaster.org/stable/Recruit.php - to name one example - you actually call that .php script, there's no redirection to index.php or anything.

As I said: Old-school.

But, your idea could still be applied. I could put the logic into .htaccess and redirect a list of URLs to index.php (of CI) and everything else to its old location. Yeah, the list would soon be long, but the total overhead would not be much more than calling two unnecessary scripts on every access.

[eluser]Dam1an[/eluser]
Infact, doesn't it make it easier now that you have multiple entry points?
Start of with any of your entry points (eg recruit.php), code it into a controller and views (and model if that part needs it), and then put a redirect into recruit.php, then move onto the next one