Moving Large Application to FW/1 - Steps/Suggestion/Blogs to read?
90 views
Skip to first unread message
Matthew Parks
Mar 12, 2018, 5:55:22 PM3/12/18
to framework-one
Everyone,
I am working on a new project and this application is a large application. The outer large application is more of an Umbrella application for 12 other applications.
My post here is to ask if others have done this before and might have some suggestions or things to avoid while I work my way through this.
The BIG applicaiton controls if users have an account into the system and what of the 12 subsystems that they might be able to get into. There are some Administation funcations that sit at this level as well.
My first thought is that do migete the "Outer" application along with the administarion part into FW/1 and that I can link over to the other 12 applicaitons as is while we peice off each application after that. Seems reasonable. Outer application is only access and links to other 12 as stated before.
The other 12 application then run Application.cfc and the extend the ApplicationProxy.cfc that is the outer application. This is the first that I have seen such a method and wondering how will I replace each subsystems application.cfc in FW/1. I can not see past this, but I am sure after getting past the vision on one application the others will fall into place after that, but this is part of my reason for the post.
Here is the current NON Frameworked layout:
wwwroot/
Application.cfc
ApplicationProxy.cfc
(other cfc and cfm pages)
wwwroot/Application1/
Application.cfc (which extended ApplicationProxy.cfc and also contains more and other onApplication, onSession, lifecycle logic specific to this app)
wwwroot/Application1/admin
wwwroot/Application2/
and so on and so on.
My idea would be so the
wwwroot/Application.cfc
wwwroot/OuterApp.cfc
but then adding the next Application, is my problem hurdle. Does it then have it's own Application.cfc and the empty index.cfm at the Applcition1 root and then extend the ApplicationProxy.cfc...
Confused. Any sugestion to reading on a bigger example than just one simple application, I need something to sink my teeth into or hit over my head.
I hope I have explained my situation. I think I have the outer application all set using links to the older other 12 applicaitons working, it is brining in the next one I am not sure of here.
I am working on a new project and this application is a large application. The outer large application is more of an Umbrella application for 12 other applications.
My post here is to ask if others have done this before and might have some suggestions or things to avoid while I work my way through this.
The BIG applicaiton controls if users have an account into the system and what of the 12 subsystems that they might be able to get into. There are some Administation funcations that sit at this level as well.
My first thought is that do migete the "Outer" application along with the administarion part into FW/1 and that I can link over to the other 12 applicaitons as is while we peice off each application after that. Seems reasonable. Outer application is only access and links to other 12 as stated before.
The other 12 application then run Application.cfc and the extend the ApplicationProxy.cfc that is the outer application. This is the first that I have seen such a method and wondering how will I replace each subsystems application.cfc in FW/1. I can not see past this, but I am sure after getting past the vision on one application the others will fall into place after that, but this is part of my reason for the post.
Here is the current NON Frameworked layout:
wwwroot/
Application.cfc
ApplicationProxy.cfc
(other cfc and cfm pages)
wwwroot/Application1/
Application.cfc (which extended ApplicationProxy.cfc and also contains more and other onApplication, onSession, lifecycle logic specific to this app)
wwwroot/Application1/admin
wwwroot/Application2/
and so on and so on.
My idea would be so the
Alternative Application Structure
wwwroot/Application.cfc
wwwroot/OuterApp.cfc
but then adding the next Application, is my problem hurdle. Does it then have it's own Application.cfc and the empty index.cfm at the Applcition1 root and then extend the ApplicationProxy.cfc...
Confused. Any sugestion to reading on a bigger example than just one simple application, I need something to sink my teeth into or hit over my head.
I hope I have explained my situation. I think I have the outer application all set using links to the older other 12 applicaitons working, it is brining in the next one I am not sure of here.
Tony Gray
Mar 13, 2018, 9:07:36 PM3/13/18
to framework-one
Hello Matthew,
Congratulations on getting a large project to build! now the fun starts. I would strongly advise some planning around the interactions of the application to get an efficient architecture design (this is pretty obvious!). I generally think of all the parts as kind of equal in terms of a system and each having a kind of responsibility or area of concern (think microservices). Each of these subsystems should literally be a stand alone application or at least perform a purpose that has a pretty well defined edge. You should be able to develop and test each subsystem independently, such that a given set of parameters can produce a "view" result (layout just a simple html wrapper to make it operational). Remember also that you don't have to produce a view in fw/1 you can create an entire subsystem (or just a controller) that acts like an API and returns data (json, xml, text etc) only.
When you have got the required subsystems working and testing in a manageable way you can then add them (as a subsystem) to a main fw/1 application.
Your main application can now manage your layouts etc. and general lifecycle interceptions. In the main application create your gateways and services and use dependency injection in your controllers and services (anywhere you need it, in any of your subsystems). AOP can very helpful too.
You can now add each each subsystem of your project with some level of sanity, like eating an Elephant, one bite at a time. F/W1 is an excellent choice as it is as simple or as complex as you want it to be and as it says on the label it won't get in your way! The people behind it, most notably Sean Corfield, and the many contributors to this small community are very knowledgeable and very helpful, though some of the veterans have moved on. I also recommend getting involved with the Lucee community as this is also a place where many Fwoners (I just made that up, not very elegant, but I couldn't think of another name) hang out and have a lot of experience developing with FW/1.
I have deliberately made this non-technical because sometimes plain English is more helpful. There are many ways to handle your project but this is a simple overview of how I do mine.
Good luck with your project.
Congratulations on getting a large project to build! now the fun starts. I would strongly advise some planning around the interactions of the application to get an efficient architecture design (this is pretty obvious!). I generally think of all the parts as kind of equal in terms of a system and each having a kind of responsibility or area of concern (think microservices). Each of these subsystems should literally be a stand alone application or at least perform a purpose that has a pretty well defined edge. You should be able to develop and test each subsystem independently, such that a given set of parameters can produce a "view" result (layout just a simple html wrapper to make it operational). Remember also that you don't have to produce a view in fw/1 you can create an entire subsystem (or just a controller) that acts like an API and returns data (json, xml, text etc) only.
When you have got the required subsystems working and testing in a manageable way you can then add them (as a subsystem) to a main fw/1 application.
Your main application can now manage your layouts etc. and general lifecycle interceptions. In the main application create your gateways and services and use dependency injection in your controllers and services (anywhere you need it, in any of your subsystems). AOP can very helpful too.
You can now add each each subsystem of your project with some level of sanity, like eating an Elephant, one bite at a time. F/W1 is an excellent choice as it is as simple or as complex as you want it to be and as it says on the label it won't get in your way! The people behind it, most notably Sean Corfield, and the many contributors to this small community are very knowledgeable and very helpful, though some of the veterans have moved on. I also recommend getting involved with the Lucee community as this is also a place where many Fwoners (I just made that up, not very elegant, but I couldn't think of another name) hang out and have a lot of experience developing with FW/1.
I have deliberately made this non-technical because sometimes plain English is more helpful. There are many ways to handle your project but this is a simple overview of how I do mine.
Good luck with your project.
Cameron Childress
Mar 14, 2018, 1:01:13 PM3/14/18
to framew...@googlegroups.com
Hi Matthew!
Without knowing more details about the application specifics, my initial thinking is that you probably want to turn this into 1 FW/1 app with 12 subsystems (or maybe 13 including the admin area). But really, the most important thing I would do first is make sure that your legacy codebase uses very predictable and consistent code conventions and file naming. FW/1 really likes things to be named consistently. Mapping a legacy system into FW/1 is far easier if the legacy app is already well organized with OCD level conventions.
I've migrated legacy apps into FW/1 several times and often I start by first pulling core pieces out of the old system bit by bit into the new using includes. For example, you could pull all your existing application settings into an include and then use that include in both the new and the old app. Do this with additional areas of the Application.cfc too. Depending how well written your legacy codebase is, with a little planning you can make the code run while included in both apps.
After that I would work on refactoring the model (CFCs) into a common format and moving those into the new FW/1 hierarchy. You can usually refactor the old app to call them remotely as well. Finally I would try to find a way to map the old code "view" templates to the new FW/1 app and make some liberal use of includes again if possible (this one is hardest just due to rc scope being used all over, which almost certainly doesn't exist in your legacy app).
The key concept for me is to have both apps running side by side for some time while you are slowly shifting the code from one side to the other. While this is happening you would potentially be able to run parts of the old app using CFC files or other bits from the FW/1 app too.
Also - you might not be getting many replies here because a large percentage of the population has migrated to Slack for these conversations. I still prefer the email list for many things, but others prefer Slack. At any rate you can signup for it here:
Hope that helps!
-Cameron
--
FW/1 documentation: http://framework-one.github.io
FW/1 source code: http://github.com/framework-one/fw1
FW/1 chat / support: https://gitter.im/framework-one/fw1
FW/1 mailing list: http://groups.google.com/group/framework-one
---
You received this message because you are subscribed to the Google Groups "framework-one" group.
To unsubscribe from this group and stop receiving emails from it, send an email to framework-one+unsubscribe@googlegroups.com.
Visit this group at https://groups.google.com/group/framework-one.
For more options, visit https://groups.google.com/d/optout.
Reply all
Reply to author
Forward
0 new messages