Fwd: Calling goso from Java?

[Konstantine Prevas]

I'm hijacking this thread from the general Gosu list as it had strayed in to Ronin discussion. My gut reaction is similar to Stephen's, but I'd like Brendan to elaborate on why he would want this functionality (I.e. why not just name the controller class whatever you want the URL to look like), and why it would be preferable to do it via reflective magic in Ronin vs. URL rewriting at the web server or servlet container level.


Begin forwarded message:

From: Stephen Haberman <stephen....@gmail.com>
Date: December 23, 2010 10:24:42 PM EST
To: gosu...@googlegroups.com
Subject: Re: [gosu-lang:266] Calling goso from Java?
Reply-To: gosu...@googlegroups.com

@Controller( pathname="admin", extension="rpg" )      

class MyController {

I'm being too lazy to move the conversation to the ronin group, but this
is way too spring mvc-ish for my liking.

Not that that is inherently evil...but it's close. :-)

- Stephen

--
You received this message because you are subscribed to the Google Groups "gosu-lang" group.
To post to this group, send email to gosu...@googlegroups.com.
To unsubscribe from this group, send email to gosu-lang+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/gosu-lang?hl=en.

[Brandon Gresham]

Well first, let me say that I am neither a Spring-expert nor a web-expert
(though I do both for a living).
Second, let me say that *I*, personally, don't see a huge need (from my
own perspective) to have these types of annotations.

However, I have shown Ronin's simplicity to several experienced web-devs
and every one of them have said that they aren't interested if annotations
(or some other way of masking the URL-components) aren't included. For
them, it seems to be something about security... they don't want their
users to know the names of actual classes/methods being called.

For me, it's more about being able to design the application in a logical
way that makes sense to me while at the same time providing URLs that are
more user-friendly. For example, I may want a class called
MySuperDuperAdminControllerUsedBySuperDuperAdmins -- but that would look
horrid on a URL and I might opt for something simpler like
ElevatedAdminController.

You asked why I wouldn't prefer to just do it vial URL-rewriting... two
reasons come to mind:
1) URL-rewriting it a whole lot harder than adding a 1-line simple
annotation -- something which is fairly standard in the industry now, and
something that is dead-simple to incorporate. It's also optional-behavior
that no developer would be required to implement but that any developer
could implement with a single line of very simple code
2) URL-rewriting (or most other approaches) mean that when a user
reports a bug when they were using a URL mapped to ElevatedAdminController
I can't do a simple CTRL-F for that controller name and be taken
immediately to the MySuperDuperAmindControllerUsedBySuperDuperAdmins class
-- no, I'll be taken to some other file entirely, possibly one that's
fairly confusing as to what exactly is happening... and I'll have to
analyze another file in order to figure out which controller-class I
should really be looking at. OTOH, a simple 1-line annotation tells me
precisely, simply, and exactly, which controller-class is at fault.

To be honest, I'm surprised at the hesitation to acknowledge how
dead-simple and helpful this sort of annotation would be. I'm starting to
suspect that, perhaps, there is a disconnect because of a lack of
Spring-experience...??? I don't know if that's true -- forgive me if it's
not... it's entirely possible that I'm missing some larger-point due to my
own naivete.

Is it a minor thing? Yes. Like I said, not a huge need from my
perspective -- but if my experience of showing it to other developers
plays out, it might be hurdle for getting Ronin (and Gosu) accepted by the
larger community.

Just a thought.
Personally, I really like Ronin's simple-approach to url-method-mapping --
I just think being able to *optionally* customize things when you want to
would be awesome.

~Brandon
PS: Merry Christmas/Hanukkah/et al!

On Fri, 24 Dec 2010 09:39:29 -0700, Konstantine Prevas <kpr...@gmail.com>
wrote:

--
Using Opera's revolutionary email client: http://www.opera.com/mail/

[Konstantine Prevas]

Don't be surprised at my hesitation - as someone who believes that Simpler Is Better, my first reaction to a feature request is always going to be to find out why you think you need it.

With no offense to your colleagues, it seems like the fear of showing actual class and method names to the user comes from a rather misguided view of "security" (though sadly a rather common one). In addition, your point about being able to quickly locate the code used to handle a particular URL is the best possible argument I can think of ~against~ any layer of indirection between URLs and class/method names.

However, I do recognize that, URLs being a user-facing component of the application, it may be necessary to provide some level of flexibility here. I'm not 100% opposed to the functionality you're describing. I don't think annotations on individual controller classes and methods are the right way to implement it, though - I'd much rather have all the URL manipulation done in one central location, via simple imperative code, so that if you must introduce a layer of indirection, at least the poor hapless soul who needs to read and debug your code knows exactly where to go and how to debug it. :)

[Brandon Gresham]

> With no offense to your colleagues, it seems like the fear of showing actual class and method names to the user comes from a rather misguided view of "security" (though sadly a rather common one).

I agree with you, actually -- but the (seemingly) large number of devs
who will struggle with this may make adoption a diffficulty.

> annotations on individual controller classes and methods are the right way to implement it, though - I'd much rather have all the URL manipulation done in one central location, via simple imperative code, so that if you must introduce a layer of indirection, at least the poor hapless soul who needs to read and debug your code knows exactly where to go and how to debug it. :)

I disagree, strongly. This is the traditional Spring approach, and it
stinks! When I was first learning Spring it was very confusing to me
to have that 3rd layer of abstraction... I would be looking for a URL
where a problem existed and it would take me to this confusing XML
file... confusing because the way the XML file was structured wasn't
immediately clear precisely what was going on... it was, <drum
roll>... *abstract*. Since introducing the annotations in 2.5,
Spring's usefulness to non-Spring-aware-devs has grown immensely IMO.
Having an annotation that is clearly marked-up with the URL in
question makes it clear that "this class/method has something to do
with your problem" -- the XML does not at all communicate that to the
novice.

Just my $0.02.

~Brandon

[Konstantine Prevas]

Oh it definitely wouldn't be an XML file, because Declarative Programming Is For Chumps. I'm envisioning something like the following in RoninConfig.init():

aliasController(AwkwardlyNamedController, "UserFriendlyName")

To be frank, if I add a feature like this as a concession to people who don't want to use Ronin in the way it's intended, the usability of that feature isn't my chief concern - I'd rather keep it as low-profile as possible. :)

One additional problem with the annotation approach is that it incurs a performance penalty at startup, since we must inspect every type in the type system in order to find controllers with the annotation. Worse, this penalty applies even to applications that aren't using the feature at all.

[Brandon Gresham]

> To be frank, if I add a feature like this as a concession to people who
> don't want to use Ronin in the way it's intended, the usability of that
> feature isn't my chief concern - I'd rather keep it as low-profile as
> possible. :)

To be clear, I'm not asking for a special concession -- I'm merely
mentioning the fact that if there are a large # of
now-Java-types-who-might-consider-adopting-gosu-except-that-there-are-several-features-they-dont-like-that-the-community-wont-adopt...
well, you might be shooting yourself in the foot to take such an
authoritative stance.

You are the coder of this project, to be sure; it's your property, do with
it what you will.
But if you fail to consider the wants of the masses, your project won't
gain the status it seems it's seeking.
IOW, I thought the aim of Gosu was an attempt to make, essentially, a
Java2 -- ie: a language more powerful than Java but still easily adoptable
by the Java-masses of coders.

Now, maybe my group is unique. Maybe 99% of java-web types *DON'T* want
annotation-support.
But by adopting a "my way or the highway"-view, you'll never really know.

Just my $0.02 -- as I've said before, I think Ronin is super-kewl.
But I'm also not the guy with 10 years of web-dev experience under my
belt; I'm a relative newb.
OTOH, the guys with 5-10 years of experience that I work with have all
complained about this.

> One additional problem with the annotation approach is that it incurs a
> performance penalty at startup,

For scripting, I can see this as a definite issue.
But for web-apps that you typically deploy-and-forget... this is a pretty
minor concern. Who cares if it takes 5sec or 30sec to deploy a web
app??? Other than during development; and I imagine that could be
countered by adding a Ronin-flag to disable that feature if you aren't
using it.

Just my $0.02. I probably sound like I'm being hyper-critical of the guy
doing the work, which I always hate. So I think it best I disengage now
-- I would hate to be the tool that demotivates an otherwise kewl project
all because of some feature that, arguably, may or may not be that
important.

I really do like Ronin -- I hope to watch it grow in the next few months,
with or without this support!
~Brandon

[Carson Gross]

To summarize a philosophical statement that Gus made earlier:

* Code, not Convention or Configuration: Everything should be done in code, with as little magic as possible, and that code should, so far as is practical, be done in debuggable, imperative Gosu.  (This is something Ronin shares with Aardvark.)  Gosu, like many of the dynamic languages, is expressive enough to support configuration-like code.

Another point that is a mix of stuff Gus has said and that (I think) we agree on:

* The development phase is *the* limiting problem in software development.  I'm convinced that one of the reasons dynamic environments like Rails are so popular is due to the change-code-hit-refresh development cycle, and the fact that server bouncing is a 10 second affair (unlike cycling a modern J2EE server.  Anything we can do to make development in Ronin more buttery will be considered with a favorable eye.

Cheers,

Carson

[Gus Prevas]

Right. I'm receptive to feature requests, but if someone is insistent
on a particular implementation of a particular feature which is at
odds with a core design philosophy of the framework, I'm afraid it may
just not be the right framework for them.