You might look at Spring Roo to see where the generation of code is going.
It is very slick. It works very nicely from the UML model.
Document the classes and "atomic" properties.
Document the relationships. "Order has a property which is a set of
Order Details and Order Details has a reference to an Order"
Document the finders "I want a findByOder" on OrderDetails, I want a
findByCustomer on Order" It can tell from the names what you want.
Document the names of the controllers you want created.
Document the controllers for which you want automatic test scripts.
request that Security be added
Feed your little script into Roo and you get a working Java webapp with
CRUD for all your objects.
Import that into Eclipse (STS version) and customize it.
Still learning how to use it but it is pretty slick. The visual
appearance is horrible but it is set up for CSS so it can be fixed up.
All of the CRUD functions are on a single page, so you do have to go in
and remap your content, menus and functions onto URLs and pages that
make sense.
It depends on Spring and AOP very heavily. The code generated is very,
very concise and readable.
I am just getting used to AOP and it looks pretty intimidating.
If we only had Spring for haXe......
Ron
Matt Gitchell wrote:
I figured this is where we'd end up.
I code in either environment with comparable speed, honestly, it's just
getting used to the workflow.
Honest! Now whether that means I code like the freakin' wind in either
or am slow as hell
in both I'll leave for you to decide. Rather than seeing the Eclipse-based
methodology as 'stupid,' I decided to consider it merely different and have
done some tweaks to get it the way I like it, which now I do.
And yes, I do 'think ahead' plenty, but that still doesn't mean that things
don't get moved around all that often. In my particular freelance world, I
end up dealing with 3rd party IT and backend guys and gals, subcontractors
of varying skill, clients who want to change scope, clients who DO change
scope (though they generally get punished financially), the gamut. Some of
these experiences mean changes of plans, which means that the refactoring
aspect is handy and saves me time.
The debug stuff is also very handy. I write code, compile, test; I
repeat this until I have a project done, for the most part. That means
that I engage the debugger more than just occasionally, I really like
having that data there.
I like these additional features, and it's worth the money to me to have
them all part of the same tool. If it saves me, say, 10 hours over the
course of owning the software, I've more than paid for it, and I've more
than paid for it.
Some of us get to work in worlds where we define all variables at the outset
of the project. We then see our projects built exactly to the class diagrams
we built when we set out to start, and we don't deviate. We then get to
write thousands of lines of perfect code, with perfect structure, then
compile it once and find that we've removed every listener, destroyed every
bitmap, caught every error, forseen every use case.
I am not one of those people, so I've bought a tool (and use a platform)
that helps compensate for that.
--Matt
On Mon, Aug 17, 2009 at 7:21 PM, Steven Sacks <flash...@stevensacks.net>wrote:
The act of writing Actionscript in FlashDevelop is, IMO, better. FD's code
completion and code gen is easier and faster. Because code completion and
code gen is the majority of what I do from moment to moment as I'm writing,
it's the better tool.
Refactoring and debugging are not what I spend the majority of my time
doing. I have Flex Builder. I use it sometimes, but not always, and
generally I use it with Build Automatically turned on while I code in FD on
the same project and it will spot compile-time errors on the fly.
FDT is a great (albeit expensive) tool, but for day to day coding, I prefer
FlashDevelop because it helps me write code faster. It might not help me
debug faster, but I spend a lot less time doing that than actually writing
code, which is where FlashDevelop shines.
I'm confused by all these comments about the strength of the refactoring
tool being a deciding factor. Do you really move stuff around packages that
often? Do you really rename entire classes that often? I find that thinking
ahead solves that problem, and when it comes up, Find and Replace in files
does a great job, even if it's a few Find and Replaces instead of just one
Refactor command.
Believe me, I (and many others) have asked the FD guys for this feature,
and it's something they're working on adding. However, it's not something I
use often enough to outweigh the benefits FD provides when actually writing
code.
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
