[Agavi-Users] Suggestion: Test for case of module name in scripts and methods
Michal Charemza
I recently found an issue when moving a project over from Mac to
Linux. I found if I create a module
"Admin"
Then on a Mac using the
AgaviContext::getModel
method works using both "admin" and "Admin", but fails on linux: I'm
assuming this is due to the fact that Mac has a case insensitive file
system...?
Also, when creating an action using "agavi action-create" and entering
"admin", the script works fine with no error, but the lower case
"admin" is used in paths / class names (and the class names do then
fail on Mac). I wonder if these issues should be fixed somehow...?
Michal.
_______________________________________________
users mailing list
us...@lists.agavi.org
http://lists.agavi.org/mailman/listinfo/users
Benjamin Börngen-Schmidt
yes if you use a case insensitive FileSystem it does not matter if you
write admin or AdMin. I had the same experience, when coding a app on
OS X :)
What I did not understand was your second question.
If you have named the Module "Admin" and then use "admin" as module
name on the action-create It will fail on OS X. But this is not really
an issue of Agavi, but rather a OS weirdness.
Just use your self a coding convention saying, that all Modules start
with an upper case letter and then also use this while coding, then
you'll be fine.
Cheers
---
Benjamin Börngen-Schmidt
benj...@boerngen-schmidt.de
Felix Gilcher
this is indeed not an issue that needs fixing. If you choose to name
you module or action "admin" because you prefer lower-case letters at
the start we let you do this. You'll need to refer to it as "admin"
with a lower case letter any where else in the code. Or do I miss
something and it fails even if you're using the same case everywhere?
felix
--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix....@bitextender.com
http://www.bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever
Simon Cornelius P Umacob
file/directory as is, without being transformed by Agavi beforehand,
so that it would behave consistently across all operating systems.
AFAIK, Mac OS X _preserves_ the case, although case-sensitivity is
optional*. Just treat your Mac as case-sensitive and you'll be fine.
[ simon.cpu ]
* You can create case-sensitive HFS+ volumes, although many apps would
no longer run.
Michal Charemza
On 26 Oct 2009, at 09:04, Benjamin Börngen-Schmidt wrote:
> What I did not understand was your second question.
> If you have named the Module "Admin" and then use "admin" as module
> name on the action-create It will fail on OS X.
If there is a module "Admin", then using the spelling
"admin" (accidentally: as I did), for the action-create script, it
will *not* fail, but I think it should produce the same error as when
entering a completely wrong module name. The script creates class
names using the capitalisation entered, so in this case the new action
class is created as:
class admin_TestAction extends MyProjectadminBaseAction
However, there is no "MyProjectadminBaseAction", only
"MyProjectAdminBaseAction", so PHP will then fail to find the base
class.
Michal Charemza
issues confused: Modules and Models (ahem). But to try to clarify:
On 26 Oct 2009, at 09:11, Felix Gilcher wrote:
> this is indeed not an issue that needs fixing. If you choose to name
> you module or action "admin" because you prefer lower-case letters at
> the start we let you do this. You'll need to refer to it as "admin"
> with a lower case letter any where else in the code. Or do I miss
> something and it fails even if you're using the same case everywhere?
It's the *lack* of failing when different capitalisation is used on OS
X that's the issue,
1. For the capitalisation of *models*, the getModel method is case
insensitive on OS X, but case sensitive on Linux. Therefore code that
works on OS X will fail on Linux (as I discovered). If the incorrect
capitalisation is used as an argument to getModel, I think it should
fail in both cases.
2. For the capitalisation of *modules*, during the action-create
script, using the incorrect capitalisation will not fail the script on
OS X: it will appear to finish properly. However, the script uses this
incorrect capitalisation in generated class names, and so then when
PHP comes to use them, it will then fail later (as I discovered). I
think the script should test for the correct capitalisation and fail
if it's wrong.
Simon Thulbourn
Michal Charemza
On 26 Oct 2009, at 09:38, Simon Thulbourn wrote:
> I'd have to agree with the other posts in this thread, that it's up
> to the developer to to ensure that he or she is entering the correct
> case/name into the build script. This stands for both of your points.
This surprises me. As:
- It leads to inconsistent behaviour between OS X and Linux. For the
model "Records" getModel('Records') and getModel('records') both work
on OS X but only getModel('Records') on Linux. It took me a while to
figure this one out when moving a project.
- The action-create script tests for incorrect spelling, but not for
incorrect capitalisation (on OS X). I have on a number of occasions
mis-spelt a module name when quickly creating an action, and the
script ended with an error and so I could quickly re-run with the
correct spelling. I have also run it using the incorrect
capitalisation, but I only figured this out later at runtime when PHP
failed.
Can I ask why it should be left to the developer? I feel I must be
missing something...
Just to be clear as well: by "incorrect capitalisation" I don't mean
without a starting capital letter. I mean something that is different
to what the existing file/folder/class name specifies. I agree that
forcing a specific capitalisation on the developer is something to
avoid.
Felix Gilcher
module name. We also should fail when the capitalization is wrong. We
could allow *creating* a new module with different capitalization but
that's another issue.
We cannot fix the getModel call unless we enforce a strict
capitalization rule but we can fix the build script to allow only the
existing module names, including capitalization.
Michal, could you please file two bug reports, one for the getModel()
call and one for the build script? There are separate issues (though
certainly related).
felix
--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix....@bitextender.com
http://www.bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever
Simon Cornelius P Umacob
On Mon, Oct 26, 2009 at 6:02 PM, Michal Charemza
<michalc...@gmail.com> wrote:
>
> This surprises me. As:
>
> - It leads to inconsistent behaviour between OS X and Linux. For the
> model "Records" getModel('Records') and getModel('records') both work
> on OS X but only getModel('Records') on Linux. It took me a while to
> figure this one out when moving a project.
To your point of view, that may be inconsistent; however, this
behavior is consistent to others.
By default, Apples ships their machines with HFS+ volumes that are
case-insensitive, but case-preserving. With this setup,
recordsModel.class.php will be stored correctly in its file system,
but you can access it via RecordsModel.class.php or
recordsmodel.class.php.
PHP is just a C application. Thus, fread() or file_get_contents()
will use standard C calls such as fopen() underneath. Under Mac OS X,
the C calls will not fail if it is given a wrong capitalization
because the file system doesn't care. This is expected behavior.
By default, Linux and Unix systems use case-sensitive and
case-preserving file systems. With this setup, recordsModel.class.php
and RecordsModel.class.php are two different files, and can co-exist
within a single directory. In this environment, the C calls will fail
if it is given a wrong capitalization because the file system cares.
This is expected behavior.
In my world, as a FreeBSD user, getModel('records') should fail for
model "Records". I strongly disagree that Agavi's behavior be changed
to adapt to wrong expected behavior.
Regards,
[ simon.cpu ]
Felix Gilcher
this problem exists also for windows users that develop on windows and
deploy on linux. It's a booby trap that explodes when you deploy. This
is not an easy problem to tackle and I guess there's no way we can
really fix that. It might be worth giving that a little thought,
that's why I asked for a bug report. We can always close it as "can't
fix" and explain the issue but then it's at least documented.
We try to be as cross-platform as possible, so we should at least try
here as well. Maybe a "warn me if case is different" option in
development might be an option. Or even "fail if case of model file is
different". That would defuse the booby trap by showing you what would
happen if you deployed on a case sensitive FS.
felix
--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix....@bitextender.com
http://www.bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever
Simon Cornelius P Umacob
On Mon, Oct 26, 2009 at 6:33 PM, Felix Gilcher
<felix....@bitextender.com> wrote:
> Hi Simon,
>
> this problem exists also for windows users that develop on windows and
> deploy on linux. It's a booby trap that explodes when you deploy. This
> is not an easy problem to tackle and I guess there's no way we can
> really fix that. It might be worth giving that a little thought,
> that's why I asked for a bug report. We can always close it as "can't
> fix" and explain the issue but then it's at least documented.
>
> We try to be as cross-platform as possible, so we should at least try
> here as well. Maybe a "warn me if case is different" option in
> development might be an option. Or even "fail if case of model file is
> different". That would defuse the booby trap by showing you what would
> happen if you deployed on a case sensitive FS.
>
I guess you're right, especially that this booby trap yields little
clues as to the real cause of the problem.
+1 for "warn me if case is different" option. I think the error
message should also inform the user about this, whenever Agavi can't
find the model/view/controller/template files...
Michal Charemza
On 26 Oct 2009, at 10:21, Simon Cornelius P Umacob wrote:
> To your point of view, that may be inconsistent; however, this
> behavior is consistent to others.
I can see what you mean, it seems like essentially it's (almost) a
choice between
- Agavi being consistent with other applications on the same system
- Agavi being consistent with itself on multiple platforms.
It's a tricky one...
However, there is the PHP class name issue. PHP classes seem to be
case sensitive on all systems, so I would argue it's better that the
arguments to getModel and agavi action-create be treated more like
parts of the PHP class names, which are case sensitive.
Michal.
Michal Charemza
On 26 Oct 2009, at 10:05, Felix Gilcher wrote:
> Michal, could you please file two bug reports, one for the getModel()
> call and one for the build script? There are separate issues (though
> certainly related).
Added:
http://trac.agavi.org/ticket/1168
http://trac.agavi.org/ticket/1169
David Zülke
> However, there is the PHP class name issue. PHP classes seem to be
> case sensitive on all systems, so I would argue it's better that the
> arguments to getModel and agavi action-create be treated more like
> parts of the PHP class names, which are case sensitive.
They aren't case sensitive, which is part of the problem.
Mind you we also lowercase module names for the module config
directives (e.g. "Default" yields "modules.default.enabled"), which is
something we cannot change for BC reasons.
We had this discussion three or four years ago and ultimately opted to
not try and fix it, because it's just not worth it.
I will close the respective ticket as wontfix later unless there are
objections. #1169 on the other hand looks like something we can
actually fix.
- David
Felix Gilcher
that either one is easily fixable. The main underlying problem is that
zodiacal-light:~ fgilcher$ touch test
zodiacal-light:~ fgilcher$ php -a
php > echo realpath('./Test');
/Users/fgilcher/Test
php > new SplFileInfo('./Test');
php > $finfo = new SplFileInfo('./Test');
php > echo $finfo->getRealPath();
/Users/fgilcher/Test
php > echo $finfo->getFileName();
Test
php > $fp = fopen('./Test', 'rw');
php > var_dump(stream_get_meta_data($fp));
array(9) {
["wrapper_type"]=>
string(9) "plainfile"
["stream_type"]=>
string(5) "STDIO"
["mode"]=>
string(2) "rw"
["unread_bytes"]=>
int(0)
["seekable"]=>
bool(true)
["uri"]=>
string(6) "./Test"
["timed_out"]=>
bool(false)
["blocked"]=>
bool(true)
["eof"]=>
bool(false)
}
php > var_dump(glob('./Test'));
array(1) {
[0]=>
string(6) "./Test"
}
php > var_dump(glob('./test'));
array(1) {
[0]=>
string(6) "./test"
}
And so on. The only solution I found so far is iterating over the
whole directory and trying to find something that matches in letters
but not in case. All other functions just lie and return the name you
gave them. However, if we fix #1169 and create the necessary code we
can also introduce the code to warn on #1168 as I proposed earlier,
that's just a config option and three lines of code in
AgaviContext::getModel().
felix
> _______________________________________________
> users mailing list
> us...@lists.agavi.org
> http://lists.agavi.org/mailman/listinfo/users
--
Felix Gilcher
Bitextender GmbH
Paul-Heyse-Str. 6
D-80336 München
T: +49 89 57 08 15 16
F: +49 89 57 08 15 17
M: +49 172 840 88 28
felix....@bitextender.com
http://www.bitextender.com/
Amtsgericht München, HRB 174280
Geschäftsführer: David Zülke, Florian Clever
David Zülke
Templates.