Best Practices Managing Server Side Front End Assets and CGI Scripts

Hello,

I'm looking for some tips on how to manage server side code related to callouts, callout GUI(css images etc), inlines etc.. basically anything custom.

Cuttently I have a lot of inline and cusotm commnd line tools and perl scripts in iw-home/custom

The CGI callout scipts and iwperl .ipl scripts that are called from FormAPI callserver() I have in iw-home/httpd/

Im more concerned about the organization,structure and location of these files than the backup procedures. Any information or examples you could provide would be great.

- Tim

Find more posts tagged with

Comments

nipper

Put them on a config branch, use a workflow to push it from iwstore to iwhome.

Put some thought into how the directories are organized. You can make sub dirs underneath the httpd and custom folders. Organize them by project/division/business unit. Put the appropriate folders under there (bin, conf, class, etc).

Don't allow anyone to change in iwhome, change in iwstore and use WF to push the changes.

Tim__D

Put them on a config branch, use a workflow to push it from iwstore to iwhome.

Put some thought into how the directories are organized. You can make sub dirs underneath the httpd and custom folders. Organize them by project/division/business unit. Put the appropriate folders under there (bin, conf, class, etc).

Don't allow anyone to change in iwhome, change in iwstore and use WF to push the changes.

So should the business unit directories contain "bin, conf, class, etc" directories or should the "bin, conf, class, etc" directories contain business unit directories?

nipper

whichever you prefer, but I like busunit/bin, conf, class

Tim__D

whichever you prefer, but I like busunit/bin, conf, class

What file types do you place in conf, class, and bin. I place .ipl files in /bin.

Also httpd is reserved for cgi webserver files only correct?

nipper

Whatever files you need. If you have config-like files, they go in conf. If you have java class files, then you need a class dir. If it is only ipl, then bin. Yes CGIs go in httpd/iw-bin/whatever/

Tim__D

Whatever files you need. If you have config-like files, they go in conf. If you have java class files, then you need a class dir. If it is only ipl, then bin. Yes CGIs go in httpd/iw-bin/whatever/

What about custom screens and other web assets css files images etc.. Do those also need to be stored in httpd? or \httpd\webapps\content_center?

Adam Stoller

What about custom screens and other web assets css files images etc.. Do those also need to be stored in httpd? or \httpd\webapps\content_center?

If they are GUI customizations - they should be located in the correct directory of the iwhome/local/config/lib/content_center/customer_src/ directory tree as per the instructions in the TeamSite User Interface Customization Guide.

If that's not what you are talking about - then please clarify the question

Tim__D

If they are GUI customizations - they should be located in the correct directory of the iwhome/local/config/lib/content_center/customer_src/ directory tree as per the instructions in the TeamSite User Interface Customization Guide.

If that's not what you are talking about - then please clarify the question

I was referring to custom CGI screens callouts etc.. not Teamsite GUI customizations. We have some legacy screens and are creating more. I want to create a structure for the images, css files etc for these custom screens to align the interfaces for ongoing CGI callout development etc..

Adam Stoller

I was referring to custom CGI screens callouts etc.. not Teamsite GUI customizations. We have some legacy screens and are creating more. I want to create a structure for the images, css files etc for these custom screens to align the interfaces for ongoing CGI callout development etc..

I believe you'd want them structured under the httpd/iw/ directory - though images you might also be able to structure under the httpd/iw-icons/ directory. In either case - I believe the suggestions already made (by others) apply - it's up to you to figure out which hierarchical structure works best for your needs.