Implemented factory around StaticJsCache.

[anaili]

Created a factory pattern for static javascript cache generation with some code cleanup and optimization.

• Package angularbean.js renamed to angularbeans.js.cache
• The ServletContextListener is no more responsible of js cache generation.
• FileLoader moved from angularbeans.js to angularbeans.util

[anaili]

@yesbutno you might be concerned by this PR. As you worked on StaticJsCache.

[yesbutno]

I'm not sure I completely understand how this works and would really appreciate some help to figure things out:

• In StaticJsCache, if I call one of the append methods after compress() the *_SCRIPT contains the uncompresses str.
• All *_SCRIPTs are publicly r/w-accessible.
• DefaultStaticJsCacheLoader seems to have nothing to do with the cache at all.
• There is only one subclass of StaticJsLoader and I can't think of at least one more meaningful subclass - so why the additional abstract base class?
• For StaticJsCacheFactoryto be usable BuildStaticJsCache() must be called - why not move the code directly into the constructor?
• In StaticJsCacheFactory all three methods have to be called in the exact order - wouldn't it be better to move the calls into an init() method in StaticJsLoader ?

Sorry for the lot of questions, but maybe you could help me out.

[anaili]

No problem, feel free to ask any questions !

• The compress logic has been separated just for future dev goals. I'm working to setup the ability to turn off this compresssion in debug environment. And enable it again in production.th It can be optimized to prevent the user from calling append* once the script has been fully generated and compressed (forgot to hide static script's fields, need more work on that).
• DefaultStaticJsCacheLoader is the class responsible of filling up these fields in StaticJsCache ( I don't know why did you say it has nothing to do with the cache).
• We created an abstract class with a default implementation for extensibility. Today we have only one implementation. But maybe in the future we'll need a new way to generate this js code. In that case, we may create a new implementation without refactoring a lot of code.
• BuildStaticJsCache may throws exceptions, uses internally reflections, allocate ressources, ... so I don't think it's good by design to put it in the constructor.
• In StaticJsCacheFactory : correct, I had to apply a template pattern in StaticJsLoader to force calling order. I'm still working on that anyway.

[yesbutno]

Thanks! And now me again ;-)

• append() / compress(): Nice. And then something like IllegalStateException when calling append() after compressing?
• DefaultStaticJsCacheLoader: My mistake. I meant getAppName() inside DefaultStaticJsCacheLoader.
• I'm asking because I'm not really a fan of premature decouplings and indirections. The later refactoring would mainly consist of "extract interface" or "extract superclass"...
• BuildStaticJsCache: Agreed. Currently the exceptions are, well, "handled" inside the method. Is there a use case where it's not necessary to call the method? My point is that it has to be impossible to get an uninitialized factory.

[anaili]

Actually, getAppName() returns the ngApp attribute's value which is mandatory in script generation because it has to be injected in 'app' module. The question now is, why we don't let the user implement the @NGApp annotated class ? Maybe @bessemHmidi has an explanation for this. About BuildStaticJsCache, I'm working on a different way to instantiate the StaticJsCacheLoader.

[yesbutno]

Oh dear. I see there's still one thing or two I can learn about the actual meaning of the codebase ;-) I only saw @Named being the only annotation that is handled in getAppName() and no access to any parts of this static js cache, and the name actually coming from the BeanRegistry...

[bessemHmidi]

i will explain anout @NGApp:

i wanted in the begining to let the user declare his app (or apps), and if not provided angularBean will provide a default one.

but after that i remarqued that with the multiple apps we need a mapping or a grouping of the different angularBeans to their app, for example something like @AngularBean(appName='app1')

and in the js side providing different js import : script src='angular-beans-core'> script src='app1.js'> script src='app2.js'>

all that need a small study to be efficient and even i thinked about AMD or asynchronous js loading, that is important for a big application. but Angular2 provide a built in dependency mecanisme so, i preferred to move the effort to that version.

Hope that was clear :)

[bessemHmidi]

@yesbutno completely undrestandable :) and sorry for the lack of code comments.