I am using the autoreload-server example which is working great for reloading namespaces on changes to the .clj files using ns-tracker.
https://github.com/pedestal/samples/blob/master/auto-reload-server/dev/dev.clj
However, it is not picking up changes to enlive templates in the resources/public dir. I've added my template paths to the vector in defn watch:
`([] (watch ["src" "resources" "resources/public" "public"]))`
As well as this in the namespaces that use enlive deftemplate:
(net.cgrand.reload/auto-reload *ns*)
However this does not work. My assumption is ns-tracker only works for clj files, and that I am using the enlive reload feature incorrectly.
Is anyone using enlive and have this figured out, or have any ideas to try?
I was hoping that Enlive Issue #6: Auto-reloading of templates was solved in early December 2013 in version 1.1.5 by this commit. But, in my testing, I cannot confirm that it is a fix. I might be doing something wrong.
A note: the example you cite, I think, dates from the pre-0.2.0 tooling changes for Pedestal. I could be wrong, but I think you'd be better off following the current documentation, not that sample file.
Pedestal's 'hello world' service app's key suggestions (which may change) are:
Use ns-tracker to figure out which namespaces to reload.
add :resource-paths ["config", "resources"] to project.clj so that Enlive can find your static HTML resources.
These steps are not enough to cause a change to a resource to trigger a reload, because ns-tracker will not pay attention to :resource-paths. Here are the details:
ns-tracker relies on clojure.tools.namespace.find/find-clojure-sources-in-dir.
clojure.tools.namespace.find/find-clojure-sources-in-dir
When you think about it, you can see why ns-tracker doesn't pick up resources; they aren't Clojure namespaces. In my opinion, this is coherent design decision, given the name, ns-tracker.
Still, pragmatically, it is clear that from the point of view of Pedestal that we do want to reload when a resource changes.
Now, let me add another thing. From a tooling perspective, let's say you do setup a watch on the resources directory. Even so, it is not easy to identify, in a granular fashion, which specific Clojure namespaces will be impacted. One resource may be used as a defsnippet by multiple deftemplate's. Therefore, one resource change can affect multiple Clojure namespaces. Strings pointing to resources might even be constructed dynamically. So, figuring out the exact minimal set of namespaces to reload may be impossible in the general case.
All of this said, it should be 'easy' and safe enough to reload all Clojure namespaces whenever a resource changes.
So, in summary, I have not solved this problem myself, but hopefully what I've explained above will help move the ball forward.
I could not find a working solution off the shelf, so I ended up writing a small ring wrapper that does the job, see https://github.com/kolov/enlive-reload
Related
I want to intercept ClassLoader's loadClass method. In order to show the process of loading class by ClassLoader. But I don't know the working principle of aspectj. It can modify the source code of the JDK?
You could just use a debugger and step through the process in order to understand it.
AspectJ can weave aspects into existing class files during compilation (CTW, compile-time weaving) or during class-loading (LTW, load-time weaving).
LTW does not work for JDK classes because those classes are always loaded before the weaving agent. So you have a bootstrapping problem there.
What you can do, however, is to apply CTW to the class files in e.g. rt.jar from your JRE/JDK distribution, zip the woven class files into another JAR and replace the original one with it. Then if you start the JVM with aspectjrt.jar on the boot classpath, you see the aspects in action. I have done that before and it works. But really, this is not what AspectJ was designed for. But you asked, so I told you. It is a very advanced topic though, and I doubt that it is the road you should take as a complete AspectJ greenhorn - no offense meant.
Update: Because I have been asked this question so often, I created a little demo project showing how to weave aspects into the JRE/JDK. I still do not think it makes sense to use it under normal circumstances, but what the heck: Why do people climb the Mount Everest? Because it exists. ;-)
In my clojurescript code I have the following:
(defn onload [] (repl/connect "http://localhost:9000/repl"))
(set! (.-onload js/window) onload)
The Clojurescript repl is very useful in development, but I am hesitant to leave it in the code during production. What is the cleanest way to have the above code present during development (simple compilation), but absent during production (advanced compilation)?
The modern-cljs tutorial actually describes exactly how to solve this here.
Hope that helps!
Unfortunately there aren't currently any well defined ways to do conditional compilation in ClojureScript.
You could add configuration variables to control whether to start a REPL in a variety of ways, but one quick and easy way would be to get the hostname of the current page, and only invoke repl/connnect if it was "localhost" or whatever other domains you're using for development work.
I think a combination of lein2 profiles and cljsbuild src-paths munging can do the trick. eg, create a namespace that simply loads your repl, and exclude it with a profile run for the final compile (possibly might need to create a dummy namespace in another src-path directory).
I am going to pick up a task that no one has ever attempted to try at my workplace. It is a CF app first written using CF 2.0 (Yes, 2.0!) 10 yrs ago with > 10 cfscheduler tasks.. We explored the idea of rewriting the app, but 10 yrs of work simply can't be rewrote in 2-3 months.
What steps shall one take to modernize the app into a maintainable, extendable state? The one that I keep hearing is "write tests", but how can I write tests when it wasn't even in MVC?
Any advice would be appreciated, thanks!
p.s. I should thank Allaire, Macromedia and Adobe for keeping CF so freaking backward compatible all the way back to 2.0!
btw, what's the most modern, maintainable state for a CF app without MVC framework? or should my end goal be ultimately refactoring it into a MVC app?? I can't image how many links I will break if I do... seems impossible... thought?
update: found 2 related Q's...
https://softwareengineering.stackexchange.com/questions/6395/how-do-you-dive-into-large-code-bases
https://softwareengineering.stackexchange.com/questions/29788/how-do-you-dive-into-a-big-ball-of-mud
I am not sure if you need to move the whole site to a MVC application. Recently I did helped with an site that was not MVC, that still had a library with the Models, Services and Assemblers in a clean and organized manor. It worked great, and we didn't need to do anything more than what was necessary.
That being said, my first step would be to organize the spaghetti code into their different purposes. It may be hard to properly create the models, but at the very least you could break out the services like functions from the pages. With that done, it should be a lot cleaner already.
Then, I would try to take the repeated code and put them into custom tags. It will make the code more reusable, and easier to read.
Good Luck!
Consider, whether a full fledged framework is really necessary. In its most basic form a framework is merely highly organized code. So if procedural, that is well organized, works leave it.
Keep in mind something like FW/1 as migration path can be better than say Coldbox if you don't need all the other stuff.
Lastly, consider this I was able to migrate a 4.5 almost 70% of the way to Coldbox (very simple and really more about directory and file organization versus IOC, plugins, modules, etc...) just using a few extra lines per file plus onMissingMethod functions.
Good Luck.
I had to deal with a similar situation for about two years at my last job, however, it wasn't quite as old as yours. I think I was dealing with code from 4.0 on. There's no silver bullet here, and you'll need to be careful that you don't get too caught up in re-factoring the code and costing your company tons of money in the process. If the app works as it is rewriting it would be a pretty big wast of money.
What I did was update small chunks at a time, I wouldn't even refactor whole templates at a time, just small portions of one at a time. If I saw a particular ugly loop, or nested if statements I'd try to clean it up the best I could. If the app can be broken down into smaller modules or areas of functionality and you have the extra time you can try to clean up the code a module at a time.
A good practice I heard from the Hearding Code podcast is create a testing harness template that would use a particular cfm page that has a known output that you can re-run to make sure that it still has the same output once you've done refactoring. Its not nearly as granular as a unit test, but its something and something is almost always better than nothing, right?
I suspect that the reason this app hasn't been touched for years is because for the most part it works. So the old adage "if it ain't broken don't fix it" probably applies; However, code can always be improved :)
The first thing I'd do is switch to Application.cfc and add some good error logging. That way you may find out about things that need to be fixed, and also if you do make changes you're know if they break anything else.
The next thing I'd do is before you change any code is use selenium to create some tests - it can be used as a FireFox plugin and will record what you do. It's really good for testing legacy apps without much work on your part.
Chances are that you won't have much if any protection from SQL injection attacks so you will want to add cfqueryparam to everything!!
After that I'd be looking for duplicated code - eliminating duplicate code is going to make maintenance easier.
Good luck!
Funnily enough, I'm currently involved in converting an old CF app into an MVC3 application.
Now this isn't CF2, it was updated as recently as a year ago so all of this may not apply at all to your scenario, apologies if this is the case.
The main thing I had to do consolidate the mixed up CFQuerys and their calls into logical units of code that I could then start porting in functionality either to C# or JavaScript.
Thankfully this was a very simple application, the majority of the logic was called on a database using the DWR Ajax library; that which wasn't was mostly consolidated in a functions.cfm file.
Obviously a lot of that behavior doesn't need to be replicated as packaging up the separate components of logic (such as they were) in the CF app did map quite neatly to the various Partial Views and Editor Templates that I envisaged in the MVC application.
After that, it was simply a case of, page by page, finding out which logic was called when, what it relied upon that then finally creating a series of UML class and sequence diagrams.
Honestly though, I think I gained the most ground when I simply hit File-New Project and started trying to replicate the behavior of the app from the top of index.cfm.
I would break logical parts of the app into CFC's
Pick a single view, look at the logic within. Move that out to a CFC and invoke it.
Keep doing that you will have something much easier to work with that can be plugged into an MVC later. Its almost no work to do this, just copy and paste sections of code and call them.
You can consider using object factory to layer your application. We have similar situation at work and we started refactoring by putting Lightwire DI framework.
First we migrated all the sql statement into gateways, then we started using services and take a lot of code out of the templates to the services.
The work is not finished yet but the application is looking better already.
For large, really complex applications I'd prefer ColdBox for a re-factor project. However, I just saw a presentation at the D2W Conference on F/W 1 (Framework One), a VERY simple ColdFusion MVC framework. Check out code from the presentation here.
It's 1 (one) CFC file and a set of conventions for organizing your code. I highly recommend evaluating it for your project.
I am new to Joomla, started learning it just a day ago and didn't manage to find an answer to my question in the docs (which suck real bad compared to Drupal).
So what I want to do is override the whole module in a template. The documentation only suggests I can override the markup of a module by placing corresponding files in the html folder, but I have to make some corrections to the actual logic. Is copying the module, changing and then installing it as a separate entity the only way to go? I mean it makes sense that "template" folder is for "views" but with the kind of application I have to develop it is gonna be annoying...
Yeah, you can only override views.
If you want to override logic, you have 2 options:
Change the actual logic in-place, which leads to problems on updating etc
Duplicate the module and change the logic, as you suggested
One other way to consider is to replicate or fix the logic in the template. While this is not a very slick way of doing it, it is faster, especially than duplicating a whole component.
Note that you can also add your own libraries to the Joomla libraries folder to centralize your own code.
Further, if you manage your code with (for example) svn, you should not have any problems on upgrades with creating new views that may include their own logic.
In my company we are using one SVN repository to hold our C++ code. The code base is composed from a common part (infrastructure and applications), and client projects (developed as plugins).
The repository layout looks like this:
Infrastructure
App1
App2
App3
project-for-client-1
App1-plugin
App2-plugin
Configuration
project-for-client-2
App1-plugin
App2-plugin
Configuration
A typical release for a client project includes the project data and every project that is used by it (e.g. Infrastructure).
The actual layout of each directory is -
Infrastructure
branches
tags
trunk
project-for-client-2
branches
tags
trunk
And the same goes for the rest of the projects.
We have several problems with the layout above:
It's hard to start a fresh development environment for a client project, since one has to checkout all of the involved projects (for example: Infrastructure, App1, App2, project-for-client-1).
It's hard to tag a release in a client projects, for the same reason as above.
In case a client project needs to change some common code (e.g. Infrastructure), we sometimes use a branch. It's hard to keep track which branches are used in projects.
Is there any way in SVN to solve any of the above? I thought of using svn:externals in the client projects, but after reading this post I understand it might not be right choice.
You could handle this with svn:externals. This is the url to a spot in an svn repo
This lets you pull in parts of a different repository (or the same one). One way to use this is under project-for-client2, you add an svn:externals link to the branch of infrastructure you need, the branch of app1 you need, etc. So when you check out project-for-client2, you get all of the correct pieces.
The svn:externals links are versioned along with everything else, so as project-for-client1 get tagged, branched, and updated the correct external branches will always get pulled in.
A suggestion is to change directory layout from
Infrastructure
branches
tags
trunk
project-for-client-1
branches
tags
trunk
project-for-client-2
branches
tags
trunk
to
branches
feature-1
Infrastructure
project-for-client-1
project-for-client-2
tags
trunk
Infrastructure
project-for-client-1
project-for-client-2
There are some problems with this layout too. Branches become massive, but at least it's easier to tag specific places in your code.
To work with the code, one would simply checkout the trunk and work with that. Then you don't need the scripts that check out all the different projects. They just refer to Infrastructure with "../Infrastructure". Another problem with this layout is that you need to checkout several copies if you want to work on projects completely independently. Otherwise a change in Infrastructure for one project might cause another project not to compile until that is updated too.
This might make releases a little more cumbersome too, and separating the code for different projects.
Yeah, it sucks. We do the same thing, but I can't really think of a better layout.
So, what we have is a set of scripts that can automate everything subversion related. Each customer's project will contain a file called project.list, which contains all of the subversion projects/paths needed to build that customer. For example:
Infrastructure/trunk
LibraryA/trunk
LibraryB/branches/foo
CustomerC/trunk
Each script then looks something like this:
for PROJ in $(cat project.list); do
# execute commands here
done
Where the commands might be a checkout, update or tag. It is a bit more complicated than that, but it does mean that everything is consistent, checking out, updating and tagging becomes a single command.
And of course, we try to branch as little as possible, which is the most important suggestion I can possibly make. If we need to branch something, we will try to either work off of the trunk or the previously-tagged version of as many of the dependencies as possible.
First, I don't agree that externals are evil. Although they aren't perfect.
At the moment you're doing multiple checkouts to build up a working copy. If you used externals it would do exactly this, but automatically and consistently each time.
If you point your externals to tags (and or specific revisions) within the target projects, you only need to tag the current project per release (as that tag would indicate exactly what external you were pointing to). You'd also have a record within your project of exactly when you changed your externals references to use a new version of a particular library.
Externals aren't a panacea - and as the post shows there can be problems. I'm sure there's something better than externals, but I haven't found it yet (even conceptually). Certainly, the structure you're using can yield a great deal of information and control in your development process, using externals can add to that. However, the problems he had weren't fundamental corruption issues - a clean get would resolve everything, and are pretty rare (are you really unable to create a new branch of a library in your repo?).
Points to consider - using recursive externals. I'm not sold on either the yes or no of this and tend to go with a pragmatic approach.
Consider using piston as the article suggests, I've not seen it in action so can't really comment, it may do the same job as externals in a better way.
From my experience I think it's more useful to have a repository for each individual project. Otherwise you have the problems you say and furthermore, revision numbers change if other projects change which could be confusing.
Only when there's a relation between individual projects, such as software, hardware schematics, documentation, etc. We use a single repository so the revision number serves to get the whole pack to a known state.