I'm not too sure on the URLBuilder as well, since it makes it hard to just simply to "get an URL, dammit." Yes, it's flexible, but it's also, well, clunky.
Yeah, but getting URLs simply, AND having some type-assurance over the parameters you pass, are diametrically opposed goals. :)
Did you take a look at the new API proposal in SVN? I think we should build a good API library first, so that we can have more freedom in building our internal core.
I have not looked at this in detail yet. A quick skim of it just now suggests that it is a little sparse so far. What sort of feedback/ interaction are you looking for?
Hm. There's one problem with Stripes which I don't like and it's the fact that it muddles the URLs. If you enter with Wiki.jsp - then you e.g. run validation on a form, you end up on Wiki.action.
That is a feature -- the .action suffix is what causes the StripesFilter to execute on the inbound side so that it can populate ActionBeans with correct parameters, run any events that are needed, check security, etc. However, the URLs are muddled generally only for things like form POST addresses. Users would see JSP URLs in their browser location bars. Directly addressing the JSP would still work.
By the way, the .action URLs also make it easy to create service URLs for things that don't have JSPs. AJAX or JSON calls, for example, could directly call the ActionBean they correspond to rather than being threaded through an AJAX servlet. This is, as you might imagine, incredibly useful. And with the integrated security annotations I've developed, we will be able to do this in a very secure way -- enforced and parameter-bound automatically through the StripesFilter, and -- here is the payoff -- *without writing a single line of code.*
So on balance -- I understand you don't like the .action suffixes. But they aren't what the user will see most of the time. And, they make life a lot easier for Dirk and other people who want to build more "web service" interfaces.
I wouldn't, since it's the officially promoted way to e.g. use the renderer engine in embedding systems. We can't break that one until 3.0.
Ok, never mind then. I am quite happy with 2.8 as it is. :)
The big problem is that WikiContext is a part of our official API, so we can't remove any of that stuff.
I meant something a little different than what you interpreted. WikiContext is pretty much here to stay -- I was not suggesting we remove it. The issue is "overloading." Should it become the parent interface for everything, or just for page-related stuff? If it's just page-related, then that means for things that have nothing to do with pages, we need a parent interface that does less (for example: a generic interface for wiki actions that does not have getPage/setPage methods).
That's the issue. Making WikiContext a pure page-specific sub- interface is probably the best approach because it breaks a lot less stuff. It just breaks the Group, UserPrefs/UserProfile and (probably) Admin JSPs, because you can't pull a WikiContext from the request any more -- you would need to cast to its parent interface ("WikiActionBean"). That was the "broken" stuff I mentioned. I think I can do that without needing to do too many modifications to the .tags package or the JSPs.
Could we continue to use WikiContext, with all of its page-centric methods, as the superinterface for all actionbeans? Sure, but then we would have to continue referencing read ("faking") the page for those 'beans that have nothing to do with pages. This is why calling getPage() for the user prefs wiki context, today, returns "Main." That is confusing, and from the user's point of view an error condition. I'd rather we stop using WikiContext this way -- that was what I meant by "overloading."
Again, the motivation here is not to remove WikiContext -- but to figure out how to extract a meaningful parent interface from it, and keeping the retrofits needed down to a minimum.
