[QUE]Custom package for Controllers
2,840 views
Skip to first unread message
Thamizh Arasu
Oct 4, 2010, 8:06:46 PM10/4/10
to play-framework
Hi,
I have a question on custom package structure for controllers. I
defined my SampleController under 'app/com/company/controllers'
folder. Then I defined this in my routes file like,
GET /sample com.company.controllers.SampleContoller.sample
But this is not working for me. Then what I did was, I moved the
SampleController file under app/controllers/com/company/controllers
folder. Now I am able to get data from my controller.
1. Here my question is that, Is it mandatory to define all controllers
under controllers folder?
2. Can I define all my controller files directly under app folder with
different package structure?
-Tham
I have a question on custom package structure for controllers. I
defined my SampleController under 'app/com/company/controllers'
folder. Then I defined this in my routes file like,
GET /sample com.company.controllers.SampleContoller.sample
But this is not working for me. Then what I did was, I moved the
SampleController file under app/controllers/com/company/controllers
folder. Now I am able to get data from my controller.
1. Here my question is that, Is it mandatory to define all controllers
under controllers folder?
2. Can I define all my controller files directly under app folder with
different package structure?
-Tham
GrailsDeveloper
Oct 5, 2010, 2:43:18 AM10/5/10
to play-framework
Hi,
I started the yabe tutorial with the same approach, but I think it's
not very clever to create a big subpackage structure under
controllers. The only reason I did it was, that this was more familiar
to me. After thinking a while I cant find a reason to organize it like
this. If you have a great application make some subpackages or better
put them directly into modules.
Just an idea to think about it.
Niels
I started the yabe tutorial with the same approach, but I think it's
not very clever to create a big subpackage structure under
controllers. The only reason I did it was, that this was more familiar
to me. After thinking a while I cant find a reason to organize it like
this. If you have a great application make some subpackages or better
put them directly into modules.
Just an idea to think about it.
Niels
Thamizh Arasu
Oct 5, 2010, 2:01:01 PM10/5/10
to play-framework
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 controllers;
I dont want to add controllers is a kind of package. So some option
should be there to remove this dependency and I want to have all my
controller files under my own package structure.
Is it possible or not?
- Tham
On Oct 5, 11:43 am, GrailsDeveloper <opensourc...@googlemail.com>
wrote:
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 controllers;
I dont want to add controllers is a kind of package. So some option
should be there to remove this dependency and I want to have all my
controller files under my own package structure.
Is it possible or not?
- Tham
On Oct 5, 11:43 am, GrailsDeveloper <opensourc...@googlemail.com>
wrote:
Michael Boyd
Oct 5, 2010, 2:04:25 PM10/5/10
to play-fr...@googlegroups.com
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).
--
You received this message because you are subscribed to the Google Groups "play-framework" group.
To post to this group, send email to play-fr...@googlegroups.com.
To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
Julien Tournay
Oct 5, 2010, 2:27:57 PM10/5/10
to play-fr...@googlegroups.com
@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.
--
Real Programmers don't need comments-- the code is obvious.
Real Programmers don't need comments-- the code is obvious.
agentcurry
Oct 5, 2010, 2:30:44 PM10/5/10
to play-framework
Thamizh,
I asked myself the same question when I first started with play. Like
Niels, I started making subs off of the controller package out of
habit. After noticing my controllers weren't being "seen" I dumped
everything into the controller dir.
It bothered me at first, and I still would like to have that ability,
but as far as I know you cannot have your own controller structure at
the moment.
I asked myself the same question when I first started with play. Like
Niels, I started making subs off of the controller package out of
habit. After noticing my controllers weren't being "seen" I dumped
everything into the controller dir.
It bothered me at first, and I still would like to have that ability,
but as far as I know you cannot have your own controller structure at
the moment.
Michael Boyd
Oct 5, 2010, 2:40:30 PM10/5/10
to play-fr...@googlegroups.com
> 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.
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.
@agentcurryAre you sure you can't add sub-packages like "controllers.User"? I have lots of them...
Julien Tournay
Oct 5, 2010, 3:03:24 PM10/5/10
to play-fr...@googlegroups.com
"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 "
When you create a play app, you're not creating a framework. The controllers you're writing are not meant to be used by anything else than your app. (unless you're writing a module, but nothing prevent you to create a controllers.mymodule package).
Obviously it doesn't make your code complex, but it's useless, and even if it's not much, I like to remove useless code.
When you write something in your code, it's usually a good idea to start thinking "Why am I doing that", if you can't think of any answer to that question (seems to be your case here, when I see your "arguments") , there's a problem somewhere.
Plus, it's breaking the convention that every Play app are using. If a new dev comes in your team, he'll search a "controllers" folder for your controllers...
Seriously, you really think that "com.smth.meh" is a better name than "controllers" for a package containing well... controllers.
"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."
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.
Generating getter/setter at compilation time saves a lot of dumb (most of the time generated by an IDE) code that makes your work less readable.
Since java doesn't evolve anymore, bringing nice concepts from the outside seems to be a good thing to me, btw you're still free to write getters/setters yourself.
jto.
Nicolas
Oct 5, 2010, 3:10:00 PM10/5/10
to play-framework
Not it is not possible. See http://www.playframework.org/documentation/1.1RC1/faq
I hope that the answer is sensible otherwise it means we need to
update the FAQ ;)
Nicolas
I hope that the answer is sensible otherwise it means we need to
update the FAQ ;)
Nicolas
Michael Boyd
Oct 5, 2010, 3:12:07 PM10/5/10
to play-fr...@googlegroups.com
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.
Julien Tournay
Oct 5, 2010, 3:15:52 PM10/5/10
to play-fr...@googlegroups.com
No Yahoo should rename their packages because they're designing APIs meant to be reusable across apps.
Seriously, did you read what I wrote, or you're just trolling ?
Even if it's not a "native" java feature, it doesn't mean it's not nice...
jto.
Julien Tournay
Oct 5, 2010, 3:16:10 PM10/5/10
to play-fr...@googlegroups.com
*should NOT
Michael Boyd
Oct 5, 2010, 3:20:44 PM10/5/10
to play-fr...@googlegroups.com
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...
Nicolas
Oct 5, 2010, 3:25:02 PM10/5/10
to play-framework
I don't understand your pb with the controllers that have to be reused
across multiple apps. If that is the case they should be in a module
(hence I don't think you need a specific namespace). If it is a
library and not a controllers they should be in the lib directory (and
it is perfectly fine to have namespaces). Where is the clash and where
is your pb exactly?
Nicolas
On Oct 5, 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.
>
> >>>>>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >>>>>> .
> >>>>> .
> >>>> .
>
> read more »
across multiple apps. If that is the case they should be in a module
(hence I don't think you need a specific namespace). If it is a
library and not a controllers they should be in the lib directory (and
it is perfectly fine to have namespaces). Where is the clash and where
is your pb exactly?
Nicolas
On Oct 5, 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...
>
>
> >>> > 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.
>
>
> >>>> @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.
>
> >>>>>> .
> >>>>>> For more options, visit this group at
> >>>>>>http://groups.google.com/group/play-framework?hl=en.
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "play-framework" group.
> >>>>> To post to this group, send email to play-fr...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >>>>>>http://groups.google.com/group/play-framework?hl=en.
>
> >>>>> --
> >>>>> You received this message because you are subscribed to the Google
> >>>>> Groups "play-framework" group.
> >>>>> To post to this group, send email to play-fr...@googlegroups.com.
> >>>>> To unsubscribe from this group, send email to
> >>>>> .
> >>>>> For more options, visit this group at
> >>>>>http://groups.google.com/group/play-framework?hl=en.
>
> >>>> --
> >>>> Real Programmers don't need comments-- the code is obvious.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "play-framework" group.
> >>>> To post to this group, send email to play-fr...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> play-framewor...@googlegroups.com<play-framework%2Bunsubscribe@go oglegroups.com>
> >>>>>http://groups.google.com/group/play-framework?hl=en.
>
> >>>> --
> >>>> Real Programmers don't need comments-- the code is obvious.
>
> >>>> --
> >>>> You received this message because you are subscribed to the Google
> >>>> Groups "play-framework" group.
> >>>> To post to this group, send email to play-fr...@googlegroups.com.
> >>>> To unsubscribe from this group, send email to
> >>>> .
> >>>> For more options, visit this group at
>
> ...
>
>
> read more »
Nicolas
Oct 5, 2010, 3:27:54 PM10/5/10
to play-framework
By problem I mean technical pb nor philosophical pb, that's another
debate ;) What is not working for you?
Nicolas
> ...
>
> read more »
debate ;) What is not working for you?
Nicolas
>
> read more »
Julien Tournay
Oct 5, 2010, 3:27:28 PM10/5/10
to play-fr...@googlegroups.com
I've never said "scala is good" (even if I think it's pretty good), I said it's not a toy...
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.
Michael Boyd
Oct 5, 2010, 3:39:28 PM10/5/10
to play-fr...@googlegroups.com
@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.
Nicolas
Oct 5, 2010, 3:58:01 PM10/5/10
to play-framework
Well, every framework force you to do things, that the way framework
works. Spring forces you to write xml configuration file to declare
the dependency injection, some others force you to write jsps, etc...
We made the choice to declare your controllers in the controllers
directory (note that we don't see that as a package but as a directory
- so com.youcompany.bla is in the controllers directory), the views in
the views directory and the models in the models directory. After
that, play isn't the only framework to do so: grails, ror do the same
for examples.
One of the problem with putting them somewhere else is that you will
have to find all the classes that extends controller and you will have
to avoid external libs, etc... plus it is taking way more time to do
so when bootstrapping the framework.
Having say that, you are not force to use play! or you are free to
modify it for your needs (but I think it is exactly what you are
doing ;) )
Nicolas
> ...
>
> read more »
works. Spring forces you to write xml configuration file to declare
the dependency injection, some others force you to write jsps, etc...
We made the choice to declare your controllers in the controllers
directory (note that we don't see that as a package but as a directory
- so com.youcompany.bla is in the controllers directory), the views in
the views directory and the models in the models directory. After
that, play isn't the only framework to do so: grails, ror do the same
for examples.
One of the problem with putting them somewhere else is that you will
have to find all the classes that extends controller and you will have
to avoid external libs, etc... plus it is taking way more time to do
so when bootstrapping the framework.
Having say that, you are not force to use play! or you are free to
modify it for your needs (but I think it is exactly what you are
doing ;) )
Nicolas
> > 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...
>
>
> >> 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.
>
>
> >>> 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...
>
>
> >>>>> > 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.
>
>
> >>>>>> @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.
>
>
> read more »
Julien Tournay
Oct 5, 2010, 3:58:51 PM10/5/10
to play-fr...@googlegroups.com
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.
Julien Tournay
Oct 5, 2010, 4:00:12 PM10/5/10
to play-fr...@googlegroups.com
Hey, you were faster than me on that one Nicolas ;)
Michael Boyd
Oct 5, 2010, 4:02:48 PM10/5/10
to play-fr...@googlegroups.com
We were talking about Yahoo's internal code.
I give up arguing with you.
Lawrence McAlpin
Oct 5, 2010, 5:08:39 PM10/5/10
to play-framework
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 »
>
> - Show quoted text -
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.
>
> 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.
>
>
> >> @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.
>
>
> >>> 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...
>
>
> >>>> 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.
>
>
> >>>>> 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...
>
>
> >>>>>>> > 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.
>
>
> >>>>>>>> @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 -
>
> >>>>>>>>> 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
>
> - Show quoted text -
GrailsDeveloper
Oct 6, 2010, 3:28:42 AM10/6/10
to play-framework
Hm I don't think that the FAQ answers the question if a crontroller
must be in the package controllers.
Niels
On 5 Okt., 21:10, Nicolas <leroux.nico...@gmail.com> wrote:
> Not it is not possible. Seehttp://www.playframework.org/documentation/1.1RC1/faq
must be in the package controllers.
Niels
On 5 Okt., 21:10, Nicolas <leroux.nico...@gmail.com> wrote:
> Not it is not possible. Seehttp://www.playframework.org/documentation/1.1RC1/faq
GrailsDeveloper
Oct 6, 2010, 3:45:31 AM10/6/10
to play-framework
@Nicolas: Thanks for clarifying the position of the play-developers. I
think it would be really useful to communicate more your design
decisions. As Lawrence I'm not agree with every design decision you
make, but I like play and can mostly live them. I think the most
frustration happens if you have such hard discussions or if you try to
make an improvement, that violates your design decisions. Furthermore
it's difficult to write code for example in modules which follows your
guide-lines. For example I don't understand why every class which have
to do with CRUD must be inner classes of the CRUD-class. I know it's
hard to document such things, as documentation in general a non
trivial job, but I would really appreciated, if you could start a side
which explain design decisions. I'm sure that such discussions as
above can become much shorter and lesser personally.
Niels
> ...
>
> Erfahren Sie mehr »
think it would be really useful to communicate more your design
decisions. As Lawrence I'm not agree with every design decision you
make, but I like play and can mostly live them. I think the most
frustration happens if you have such hard discussions or if you try to
make an improvement, that violates your design decisions. Furthermore
it's difficult to write code for example in modules which follows your
guide-lines. For example I don't understand why every class which have
to do with CRUD must be inner classes of the CRUD-class. I know it's
hard to document such things, as documentation in general a non
trivial job, but I would really appreciated, if you could start a side
which explain design decisions. I'm sure that such discussions as
above can become much shorter and lesser personally.
Niels
>
> Erfahren Sie mehr »
Erwan Loisant
Oct 6, 2010, 5:17:27 AM10/6/10
to play-fr...@googlegroups.com
Hi,
It's perfectly possible to have discussions about these choices in
this list without ending up in a flamewar. When a design choice
surprises you, even if you feel it's a stupid decision just ask
politely why it's this way. If you disagree with the decision you can
still argument but keep the arguments as objective as possible.
Eventually, understand that an Open Source project is not a democracy,
there's a project leader and a team of core developers who take
decision you may not agree with. The beauty of Open Source is that
you're always free to fork. Now that we're on github, it's even easier
to fork and keep your version up to date with the official repository
(if you really want to). Of course it may not be the wisest thing to
do, extending the core with modules is much easier to manage.
Now some decision could be arbitrary, but the most important is the
consistency within the project. For example Play's source code is
indented with spaces, and while using tabs is a perfectly valid choice
we don't want to mix the two. We also don't want to change from spaces
to tabs because it would be completely useless. So for such minor
things the best is to comply for the sake of consistency.
If you want to avoid frustration when you code a patch, the best is to
discuss it first. One way is to discuss it here, a better way is to
start by opening a bug. You explain what you feel should be changed,
that you propose to do it in a certain way. Then a discussion can
start and you can be sure before writing your patch that it will be
welcomed by the core team. If the change is not wanted you will know
it before you start.
Regarding modules: core modules (crud, secure...) are part of the
official distribution so they need to respect the style and
guidelines. For your own modules on the other side, you can just use
whatever style and pattern you want! The same goes for your
applications.
On Wed, Oct 6, 2010 at 09:45, GrailsDeveloper
<openso...@googlemail.com> wrote:
> @Nicolas: Thanks for clarifying the position of the play-developers. I
> think it would be really useful to communicate more your design
> decisions. As Lawrence I'm not agree with every design decision you
> make, but I like play and can mostly live them. I think the most
> frustration happens if you have such hard discussions or if you try to
> make an improvement, that violates your design decisions. Furthermore
> it's difficult to write code for example in modules which follows your
> guide-lines. For example I don't understand why every class which have
> to do with CRUD must be inner classes of the CRUD-class. I know it's
> hard to document such things, as documentation in general a non
> trivial job, but I would really appreciated, if you could start a side
> which explain design decisions. I'm sure that such discussions as
> above can become much shorter and lesser personally.
> Niels
>
--
Erwan Loisant
Nicolas Leroux
Oct 6, 2010, 5:24:23 AM10/6/10
to play-fr...@googlegroups.com
Hi Niels,
I think you are completely right, we need to better communicate.
There is only one minor problem at the moment:
We are all coding, document and answering emails on our free time, this means that most of the time we simply don't have enough time, especially when you are working full time, have a family, etc, etc...
However, as soon as it is possible, we will try to better explain the design decisions.
Thanks for your feed back :)
Nicolas
GrailsDeveloper
Oct 6, 2010, 5:51:58 AM10/6/10
to play-framework
Hi Erwan,
I'm totally agree with you that an Open Source project is not a
democracy. Nevertheless it's good to discuss decisions and explain why
you do something or why you reject something. In the past I have
sometimes the situation where this didn't happens. For example I
propose a patch and was wondering why I don't get a feedback and after
a few weeks I get the information in a discussion about another topic,
that the coreteam has look at my patch and see that I add some
functions to an interface, so other modules would become broken. For
me this decision is quite ok, but as I learned that was a no-go. Which
I quite accept, but it would be useful to get the feedback directly
and better if this no-gos are described. I could give you more
concrete examples if you wanted.
You wrote:
"It's perfectly possible to have discussions about these choices in
this list without ending up in a flamewar. When a design choice
surprises you, even if you feel it's a stupid decision just ask
politely why it's this way."
I would say this thread starts with a politely question, I recommend
in my first post to have think about why packages are not always so
useful and find this morning a flamewar. If I had has the possibility
to link to an explanation I guess we don't have had this discussion.
To make it short: My personal impression is, that it would be useful
to add a little bit more time into communication. For me this is more
important than the decision between git or bazaar. I remember the
coreteam on this topic if I get examples for my impressions like this
thread. I hope this isn't annoying, I only want to improve the project
playframework outside the code part. For me this is for example
documentation or still feedback about my impression, specially if I
think that other has the same impression. And to make it clear: I
think the core-team has made a really great job. The code is mostly an
inspiration for my thoughts about java.
Thanks and sorry for my English.
Niels
I'm totally agree with you that an Open Source project is not a
democracy. Nevertheless it's good to discuss decisions and explain why
you do something or why you reject something. In the past I have
sometimes the situation where this didn't happens. For example I
propose a patch and was wondering why I don't get a feedback and after
a few weeks I get the information in a discussion about another topic,
that the coreteam has look at my patch and see that I add some
functions to an interface, so other modules would become broken. For
me this decision is quite ok, but as I learned that was a no-go. Which
I quite accept, but it would be useful to get the feedback directly
and better if this no-gos are described. I could give you more
concrete examples if you wanted.
You wrote:
"It's perfectly possible to have discussions about these choices in
this list without ending up in a flamewar. When a design choice
surprises you, even if you feel it's a stupid decision just ask
politely why it's this way."
in my first post to have think about why packages are not always so
useful and find this morning a flamewar. If I had has the possibility
to link to an explanation I guess we don't have had this discussion.
To make it short: My personal impression is, that it would be useful
to add a little bit more time into communication. For me this is more
important than the decision between git or bazaar. I remember the
coreteam on this topic if I get examples for my impressions like this
thread. I hope this isn't annoying, I only want to improve the project
playframework outside the code part. For me this is for example
documentation or still feedback about my impression, specially if I
think that other has the same impression. And to make it clear: I
think the core-team has made a really great job. The code is mostly an
inspiration for my thoughts about java.
Thanks and sorry for my English.
Niels
Thamizh Arasu
Oct 6, 2010, 2:07:07 PM10/6/10
to play-framework
Hi,
I am assuming that it is not necessary/possible to create sub-packages
to create the user defined controllers. But the Play framework assumes
all controllers need to be packaged under app/controllers and all
controller code needs to start with package name "controllers".
Can anyone confirm this?
- Tham
I am assuming that it is not necessary/possible to create sub-packages
to create the user defined controllers. But the Play framework assumes
all controllers need to be packaged under app/controllers and all
controller code needs to start with package name "controllers".
Can anyone confirm this?
- Tham
Erwan Loisant
Oct 6, 2010, 2:44:01 PM10/6/10
to play-fr...@googlegroups.com
On Wed, Oct 6, 2010 at 20:07, Thamizh Arasu <thamizh...@gmail.com> wrote:
> Hi,
>
> I am assuming that it is not necessary/possible to create sub-packages
> to create the user defined controllers. But the Play framework assumes
> all controllers need to be packaged under app/controllers and all
> controller code needs to start with package name "controllers".
>
> Can anyone confirm this?
> Hi,
>
> I am assuming that it is not necessary/possible to create sub-packages
> to create the user defined controllers. But the Play framework assumes
> all controllers need to be packaged under app/controllers and all
> controller code needs to start with package name "controllers".
>
> Can anyone confirm this?
Yes, you can put your controllers in
"controllers.com.mydomain.myproject" if you want.
> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>
--
Erwan Loisant
Reply all
Reply to author
Forward
0 new messages