Component Development best practices?

pwoolcoc

I am a web dev. with limited Java knowledge, who has to develop a number of LiveSite/SitePublisher components. I have a couple of issues with my development process that I think could be improved, but have been unable to find suitable solutions for, and was hoping the community could give me some tips.

Right now I develop in Eclipse on my local machine. Both my machine and the TS server are Windows machines, so I map the TS server C: drive as a network drive, and add the LiveSite JARs to my build path via this network drive. When it comes time to deploy, I use the network drive to copy the exported JAR to the TS server, and rebuild the toolkit in a cmd window via a Remote Desktop connection to the TS server.

While developing, I use static main() functions for small-scale testing of as many methods as possible. However, trying to test methods that take a RequestContext or PropertyContext is difficult, since those classes can't be instantiated. Anyone have any suggestions about this? Right now in order to see if a change to one of these methods was successful, I have to export the JAR, rebuild the toolkit, wait for the TS UI to reload (sometimes takes a few minutes), then try previewing the component. It is frustrating to say the least.

Thanks in advance for any help.

Ranveer

While developing, I use static main() functions for small-scale testing of as many methods as possible. However, trying to test methods that take a RequestContext or PropertyContext is difficult, since those classes can't be instantiated. Anyone have any suggestions about this? Right now in order to see if a change to one of these methods was successful, I have to export the JAR, rebuild the toolkit, wait for the TS UI to reload (sometimes takes a few minutes), then try previewing the component. It is frustrating to say the least. Thanks in advance for any help.

You can use main method to test the response of the class. Whatever value you getting from the context can be set hard-code and at the time of final deployment you can change it to dynamic.

i.e:
if you getting some value from context.getParameterString("name");
you can set it hard-code to name = "some value";

trying to test methods that take a RequestContext or PropertyContext is difficult, since those classes can't be instantiated.

now you can remove the RequestContext from parameter.

If method return type is Document type then you can print it on console asXML.

hope this will help you..