Messages
Reply
Edit
Delete07:40 am
3SP0GG6Q0
| From: | Jeff Barefoot |
| To: | Rick Strahl |
If you're using Process Classes there's not a lot of things you can do to modularize as the class has to have at least all the endpoint methods that receive the calls.
Within the calls though try to make it so there's only a minimal amount of code in these methods. Essentially they should only organize the view or template to be rendered - the rest of the code should come from business objects. In most of my applications the majority of process methods are only a handful of lines long. If they are much longer you can probably delegate.
Another option if you have too many endpoints in a single process class is split it into multiple process classes. Different extensions or different folders so you can figure out the routing of which process class to call. For example in one of my apps I look at the base folder below the virtual that is used. If it's /wconnect/foo/mypage.tst I go to my foo process class, if it's /wconnect/bar/mypage.tst I go to the bar process class. It just takes a little extra processing in the routing code in YourAppMain.prg and the Process method to inspect the URL and instantiate the proper Process class to execute.
An even easier way is to simply use a different script map which provides automatic routing.
Another option: You can create handler classes that simply forward to Process class to the handler class. So you can create a process method like this:
DEFINECLASS MyProcess as wwProcess ...FUNCTION MyProcessMethod() loHandler = CREATE("MyAppProcessHandler")RETURN loHandler.MyProcessMethod(this)ENDFUNCFUNCTION MyProcessMethod() loHandler = CREATE("MyAppProcessHandler")RETURN loHandler.MyProcessMethod2(this)ENDFUNCFUNCTION AnotherProcessMethod() loHandler = CREATE("AnotherProcessHandler")RETURN loHandler.AnotherProcessMethod(this)ENDFUNCENDFUNCENDDEFINE
What this does is forward each request to a separate handler of your choice. You can now create as many classes as needed to handle each of the requests and effectively break the logic into many separate code files (like the last class is different than the first two). Each of the handler files then can still reference all the Process class features and all the other intrinsic objects like Process, Server, Request, Response) because they are all still in scope. Only thing that breaks when moving code this way is use of this. for Process class methods.
Finally if you use the Web Control Framework and 'pages' each page is fully self contained, so the level of abstraction is each request handler is a class is the default model with that approach.
+++ Rick ---
My WebProcess.prg contains all of the custom functions that do the work and call the individual pages in my WebConnect application (pretty standard...I think that's the way that it would normally work). It's working just fine, but becoming a little unwieldy. It currently contains 30 custom functions, and about 4000 lines of code. Not huge...I know...but I'd love to be able to organize my functions by type (reporting, security, utility, viewing data, etc).
What is the "Best Practice" for WebProcess? Is it easier to keep everything in a single .prg and bounce up and down to access, or is there an easy way to create multiple .prg's to contain the neatly organized functions? If there is an easy way to make the change, can you point me to an example of how to make it work?
It's not a big deal, and I don't want to spend a lot of time on it....was just hoping that there might be a quick way to reorganize my stuff.
Thanks,
Jeff
