greg buela

Ranch Hand
+ Follow
since Sep 04, 2007
Merit badge: grant badges
For More
Cows and Likes
Total received
In last 30 days
Total given
Total received
Received in last 30 days
Total given
Given in last 30 days
Forums and Threads
Scavenger Hunt
expand Ranch Hand Scavenger Hunt
expand Greenhorn Scavenger Hunt

Recent posts by greg buela

Thanks, I got it. My IDE was set to exclude .java files when packaging.
15 years ago
How do you tell the compiler to include the source files in the destination JAR, along with the bytecode?
15 years ago
Thanks Bear.
I try to keep usage of the session scope to a minimum and I thought that maybe this would already be too much.
16 years ago
Looking for suggestions.
Say you process a request and your service or model produces a bunch of validation messages (for example, one for each required field that was left empty). These are message keys to be resolved through a i18n bundle. Say you may need to parameterize some messages, for example to inform the maximum size for a given field. So far so good.
Now, say that this request does not forward to a view, but issues a sendRedirect which triggers a GET from the client. This new request yields a view which should be capable of displaying the messages correctly. How would you go about doing this?
The easiest way out seems to be storing everything in the session scope so it's available in the next request. The new request should clear that stuff immediately after use.
Is there a better way?
16 years ago

Originally posted by Ben Souther:

You're thinking of the commands as being part of the Model in MVC.
Instead, think of them as a part of the controller.

Hi Ben,
No, I wasn't thinking of them as part of the model. They are of course part of the controller.
I was thinking more of reusing the commands to work with a different servlet implementation, maybe one that isn't a HttpServlet. In that case, commands shouldn't be dealing with anything that is HTTP specific. My framework has a CommandContext interface and the implementation HttpCommandContext. The commands, however, only work with the interface. It gives you access to the usual things you'd do with http request and response, but indirectly.
Like I said before, this point I'm making may prove to be of little value in the real world: for a different environment we might find it more useful to deal directly with our service interface, or to build a new kind of commands. So it's definitely not a serious objection...
One problem I have with my approach is that, as I find, my commands need to be aware of redirection after non-idempotent operations (I even want to enforce the post-redirect-get pattern). These concepts are inherent of the request/response architecture as in HTTP. Dealing with these things in other scenarios could be meaningless, although it should still work.
16 years ago
I tend to think that the effort of implementing and maintaining a design with the abstract factory pattern might not be worth it when you have a dependency injection framwork like Spring. At least not when the deployed application is going to use only one implementation of the factory. Instead of creting the objects in a factory, I'd have them injected. A different configuration file would be used to inject a different set of objects (alternative implementation). Yes, it would be easier to just inject a factory and not each object, but you'd still have to write the concrete factories with the code to instantiate all those objects. So, is it worth it? what do you guys say?
OK, looking at Front Man's javadoc, I have a couple of suggestions to make.
The first is something I mentioned in the previous post: your CommandContext is tied to the web environment, as it knows about HttpServletRequest's, etc; therefore so are your Commands, which take a CommandContext. I don't know if anybody would be concerned about it, we are most likely never going to need to port our apps to a non-web platform; and if we do, we'd be happy to reuse service and persistence layer, and just rewrite the MVC. Still, I thought it would be cool to minimize, or avoid, ties to the web at the Command, if only to help with my jUnit tests. My CommandContext, just like yours, has access to scoped variables, and things like request path, etc., but only the HTTP implementation has ties to the web platform. (Actually I need to get this better, but that's the idea.)
A second thing I'd like to suggest, and maybe this is sounds more useful, is to have an overloaded forward() or redirect() that instead of taking a String argument, takes a Command class argument. This is better for refactoring when a class changes name.
I have calls like this:
In the method calls that take a String, I also thought it wasn't necessary to distinguish between a View target or a Command target. The front controller servlet has the means to tell a command string from a view string, and the string itself should also be easily identifiable as a view or command to a developer. These are my 'next action' signatures:
setNextAction(Class) // forward to command
setNextAction(String) // forward to command or view
setNextActionRedirect(Class) // redirect to command
Here's another principle that I'm enforcing, from a best practice: no direct client access to a view, always go through the controller. That's why I don't even have a redirect that takes a String. Also I take views to be by default under WEB-INF, which makes them inaccessible to the client directly.
I hope this feedback is of any use, it's also open to criticism, of course
[ November 08, 2007: Message edited by: greg buela ]
16 years ago
Hi Bear,
Remember we have recently talked about this stuff? I had guessed right what your next move was going to be. This whole idea has also been going on in my mind, and well, I haven't even tried RoR but its principles are inspiring. It turns during this time I have also been developing my own lightweight front controller / command framework. Though I'm already using it in a practice project, I still consider it in the works. I'm gladly surprised to see (in the comments here) that you have a CommandContext, because I came up with the exact same idea, in a class with exactly the same name
I have chosen to load the commands on demand and keep them alive. (Edit: bullcrap, I just checked and I don't keep them alive. They are created and discarded.) There is never more than one instance of a command, and of course they must be thread safe. They're not supposed to keep state. I think this restriction doesn't hurt a good design with the command pattern, the commands do minimal stuff and delegate to platform-independent service objects. (The CommandContext ideally should abstract the commands themselves from the web platform but I don't think I have quite achieved that!)
I have also chosen to have no URL-command mappings at all, commands are always inferred. A root package is defined as a servlet parameter in order to let the front controller find the right class. This was my original idea, but I have made it to support subpackages. So you have the restriction of having all your commands under one package but they can still be organized.
OK, I guess I now should take a good look at what you've done. I kind of feel like reinventing the wheel with so many frameworks out there, but I couldn't resist making it (it's not big anyway). Whatever I end up using, one thing I'm sure of, I will never chose a design with multiple servlets. I have only been through that experience once (it wasn't my choice) and I've had enough!
[ November 08, 2007: Message edited by: greg buela ]
16 years ago
This has happened to me today, and I've found what was wrong.
I had created a folder where I put my test classes (which were developed in another IDE). The problem is that this folder wasn't created as a "source folder".
You can easily tell whether your test folder is a source folder: in the package explorer, check out the icon for that folder. It should be the same as for the src folder.
So if that was your problem too, right click on the project node, select New... and then Source folder. Then just put your tests in that folder.
Sounds like this should be a language feature! The aspect looking at annotations is good. But it would be great to just have...

public void myMethod(notnull MyClass mc1) { ... }

... and get it to automatically throw the exception with a descriptive message.
Yes, I thought of that too, and it is clearer.
Considering this exception most likely implies a bug, I thought it wasn't worth being so specific. The problem has to be traced anyway. But of course, I can't make it simple enough to have a single argument because that will provide no information at all. The next simplest thing was to pass a class argument. But if we must use at least 2 args I may just as well use a message instead of the class.
I was wrinting some DAO methods and found myself checking for null arguments a lot. I came up with this. Does anybody see something wrong in adopting this practice?

Edit: OK, let's pretend I didn't make the terrible mistake of trying to obtain the class from a null reference

Say the require method takes a second argument with the class or class name!

[ October 30, 2007: Message edited by: greg buela ]
[ reduced tab width for readability ]
[ October 31, 2007: Message edited by: Frank Carver ]
Mmmm... I don't know about what you read by Kathy Sierra, but the variable is still protected. Try it out. Protected variables are visible in subclasses and sub-subclasses.
Interesting problem. I remember programming the Commodore 64 which had built in sprite collision detection. Who'd say that 20+ years later there would be a discussion about how to detect collision with a far superior language!
16 years ago