Michael, every framework needs to be configured in some fashion.
In a servlet container you would enumerate your servlets in web.xml.
JPA similarly requires either a declaration in a persistence.xml or it
scans for annotations.
JSF makes you either declare beans in a faces-config.xml or annotate
them with @ManagedBean.
Play! is very much influenced by Rails. And, just like Rails, there
is a folder (or package)
naming convention you MUST follow. It does this because that's how it
knows what the classes
are intended for.
If it did not force you to use those package naming conventions, you
would have to either use
XML or annotations to configure. That's the way everyone else does
it. Personally, I'm glad
the Play! framework came along and gave us another option because I
personally don't like
littering my code with XML (which is not type-safe and can lead to
runtime errors) or
annotations (some of the EJB+CDI+JSF+JPA programs I've seen in the
enterprise these days are
like 80% annotations and 20% code.)
If you don't like the conventions that Play! uses, you have three
choices:
1) use another framework that is more to your liking - JSF, Wicket,
Stripes, Click, Struts,
there are dozens of them out there
2) write your own framework
3) take Play!, fork it, change the bits and baubles you don't like,
and make your own version
that shows the world how it should have been done... if the world
agrees, I'm sure the guys
at Zenexity will be humble enough to roll your changes into the
framework proper just like
Rails merged with Merb.
Personally, I don't agree with every design decision that the Play!
designers either, but
it's refreshing to see someone take some of the good ideas from
outside of the XML- and
annotation-laden world of Java programming. And not being able to
call my packages
com.lmcalpin.awesome.programmer.extraordinaire.programname.controllers
isn't really something
I really give a damn about when I get to avoid the annotation and XML
hell I'm accustomed to
from every other Java framework out there in return.
On Oct 5, 4:02 pm, Michael Boyd <
mic.t.b...@gmail.com> wrote:
> We were talking about Yahoo's internal code....
>
> read more »
>
> I give up arguing with you.
>
>
>
> On Tue, Oct 5, 2010 at 8:58 PM, Julien Tournay <
boudhe...@gmail.com> wrote:
> > Yahoo guys are designing API to be used OUTSIDE yahoo, for god sake, read
> > what I wrote, and try to understand my point just a little...
>
> > There's no point arguing with you, you don't read what people wrote, you
> > didn't even read the page Nicolas sent to you.
>
> > If you don't like what Play does with packages, add this feature to your
> > fork and use it.
> > You now know that it's not something that gonna change in the "official"
> > Play.
> > I would have liked if you had thought about this at least for 1 minute,
> > obviously you didn't.
>
> > Saying that it's not the standard way of doing things is not an argument...
> > Seriously, wake up guy Play! IS NOT STANDARD, it's not even JEE!
> > If you wan't something that is totally standard, there's JSF out there
> > (have fun with it).
>
> > jto.
>
> > On Tue, Oct 5, 2010 at 9:39 PM, Michael Boyd <
mic.t.b...@gmail.com> wrote:
>
> >> @Nicolas - There isn't a problem, and I would just rename them I there was
> >> a naming conflict. But it's not about a problem. It's about Play FORCING
> >> controllers to be in "controllers." instead of letting the developer decide.
> >> How would you like it if Java forced you to write all your classes inside
> >> "notOfficialJavaClasses." package?
>
> >> @Julien Tournay - Dude, you gotta stop contradicting yourself. Earlier on
> >> you said (I'm para-phrasing), "Yahoo should not remove 'com.yahoo' because
> >> the classes are an internal API, even though they will never be used outside
> >> of Yahoo". Now you are saying, "Michael should remove 'com.company' because
> >> the classes are an internal API, and they will never be used outside of
> >> Company." The only different in those sentences is that Yahoo should keep
> >> "com.yahoo" but I should not keep "com.company". Yet the scenarios are the
> >> same.
>
> >> I'll say it again: Play is messing with the standard way of doing things
> >> without a good reason.
>
> >> On Tue, Oct 5, 2010 at 8:27 PM, Julien Tournay <
boudhe...@gmail.com>wrote:
>
> >>> I've never said "scala is good" (even if I think it's pretty good), I
> >>> said it's not a toy...
>
> >>> You're controllers are reused inside your company, and probably only by
> >>> yourself or your team.
> >>> If they don't go "outside" there's no possible conflicts, plus you'll
> >>> probably never add multiple auth controllers from different companies in a
> >>> single app.
>
> >>> jto.
>
> >>> On Tue, Oct 5, 2010 at 9:20 PM, Michael Boyd <
mic.t.b...@gmail.com>wrote:
>
> >>>> Also, using Twitter as a reason why Scala is good... probably doesn't
> >>>> help your argument, considering Twitter is down so often and is quite buggy.
> >>>> :)
>
> >>>> I have controllers that are to be re-used across multiple apps. I have a
> >>>> package called "controllers.authentication" that is used across 5 different
> >>>> sites/applications. Hence I should NOT remove the "com.company" part (like
> >>>> you just wrote about Yahoo) because it is re-used. See?
>
> >>>> > Even if it's not a "native" java feature, it doesn't mean it's not
> >>>> nice...
>
> >>>> This has nothing to do with "nice". It has to do with what Play IS. It
> >>>> IS Java, it is NOT Scala, even though there is an optional module for Scala
> >>>> which is in your opinion "nice". Re-read the part about Quercus/PHP above...
>
> >>>> On Tue, Oct 5, 2010 at 8:12 PM, Michael Boyd <
mic.t.b...@gmail.com>wrote:
>
> >>>>> What you said about packages made no sense. Answer this: should Yahoo
> >>>>> remove "com.yahoo" from all their package? Should Google remove "com.google"
> >>>>> from all their packages? If your answer is yes, please don't waste my time
> >>>>> replying. If the answer is no, then you lost the argument. Get it?
>
> >>>>> > First Play! IS scala, there's a module for that, and scala is not a
> >>>>> toy, there's a little app called twitter using it.
>
> >>>>> Except Play isn't Scala. There is a MODULE for Scala. Very different
> >>>>> things. If I wrote a plugin for Quercus (a PHP-Java bridge), Play would
> >>>>> still be Java, not PHP. Your point about Twitter has nothing to do with
> >>>>> this. I said it might be YOUR favorite new toy, not that it IS a toy.
>
> >>>>>> On Tue, Oct 5, 2010 at 8:40 PM, Michael Boyd <
mic.t.b...@gmail.com>wrote:
>
> >>>>>>> > Why would you like to add a complex package structure to your
> >>>>>>> controllers?
> >>>>>>> > You wont use them outside of a Play! app, it doesn't make sense to
> >>>>>>> add such a package structure.
>
> >>>>>>> I really can't take any of your arguments seriously after such a
> >>>>>>> statement. Are you serious?
>
> >>>>>>> If the Yahoo CTO said "hey, we're going to remove the com.yahoo part
> >>>>>>> from all our packages because nobody else uses them and the extra 9
> >>>>>>> characters make our code complex", he would be sacked on the spot. Please
> >>>>>>> realize what you just said is terribly wrong.
>
> >>>>>>> > it's just bring one of the nice features of scala into the java
> >>>>>>> world.
>
> >>>>>>> Play isn't Scala. It's Java. Don't try make a language work like
> >>>>>>> another just because the new one is your current favorite toy.
>
> >>>>>>> @agentcurry
>
> >>>>>>> Are you sure you can't add sub-packages like "controllers.User"? I
> >>>>>>> have lots of them...
>
> >>>>>>> On Tue, Oct 5, 2010 at 7:27 PM, Julien Tournay <
boudhe...@gmail.com>wrote:
>
> >>>>>>>> @Thamizh
> >>>>>>>> "we should add the package statement like, package controllers;"
>
> >>>>>>>> controllers IS a package, and like every other package you have to
> >>>>>>>> put "package controllers;" at the beginning of your file.
>
> >>>>>>>> @Micheal
> >>>>>>>> Saying that "it's silly" is definitely not an argument.
>
> >>>>>>>> Why would you like to add a complex package structure to your
> >>>>>>>> controllers?
> >>>>>>>> You wont use them outside of a Play! app, it doesn't make sense to
> >>>>>>>> add such a package structure.
> >>>>>>>> In case you didn't notices, Play is nice because you don't have to
> >>>>>>>> bother too much with conf, and you don't have to bother with conf thanks to
> >>>>>>>> conventions.
> >>>>>>>> There's no added value in changing the controller package, it just
> >>>>>>>> add a little more complexity, with no gain. That's what I would call silly.
>
> >>>>>>>> Mixing tags and views in the same folder doesn't seem to be a good
> >>>>>>>> idea to me, but it's just a matter of taste.
>
> >>>>>>>> And even if Models fields are declared public, Play generates
> >>>>>>>> getters and setters "behing the scene", it's saves a lot of boilerplate
> >>>>>>>> code, and don't break encapsulation. It's not silly, it's just
> >>>>>>>> bring one of the nice features of scala into the java world.
>
> >>>>>>>> jto.
>
> >>>>>>>> On Tue, Oct 5, 2010 at 8:04 PM, Michael Boyd <
mic.t.b...@gmail.com>wrote:
>
> >>>>>>>>> I totally agree, Thamizh.
>
> >>>>>>>>> Play shouldn't force developers to do things in silly ways. The
> >>>>>>>>> controllers package is one of those silly things; others are putting tags in
> >>>>>>>>> "/views/tags" instead of "/views", and having Model fields public. I changed
> >>>>>>>>> some of them here:
http://code.google.com/p/play-lights51/(controller
> >>>>>>>>> package hasn't been changed yet, but I'll do that soon).
>
> >>>>>>>>> On Tue, Oct 5, 2010 at 7:01 PM, Thamizh Arasu <
> >>>>>>>>>
thamizh.s.ar...@gmail.com> wrote:
>
> >>>>>>>>>> Hi,
> >>>>>>>>>> Sorry to say that, I am not convinced with your answer. As a java
> >>>>>>>>>> developer the traditional package structure should be maintained.
> >>>>>>>>>> When
> >>>>>>>>>> we add our controller files under controllers folder, we should
> >>>>>>>>>> add
> >>>>>>>>>> the package statement like, package- Hide quoted text -
>
> - Show quoted text -