personal considerations

[Franco Ponticelli]

Hello Group,
I've started using haxigniter and I wanted to share my first
impressions. Take them considering that I am still at the beginning of
learning it but I am not new to web development. So feel free to
ignore my thoughts if you don't like them ;)

* Even if packaged as a haxelib, haxigniter doesn't fit the usual
philosphy for haxe libs. What I mean is that you cannot easily do -lib
haxigniter because you have to change files from the lib itself
(config, controllers ...). I understand that this is a totally
different approach (more symfony or ruby style for what I know) and I
am not saying it must be changed, I am just pointing it out

* Use of getters in controllers seems a little odd to me. Accessors
are great when used in a public API because the developer is forced to
use them instead of the getSomething function. But in controllers,
which most likely are accessed by inherited classes, you always have
both available (the getter function and the property) and the
developer may wonder why. Also from an autocomplete point of view it
is annoying because you have a lot of duplicates available. In my
opinion those properties should be moved to an instance of a different
class accessed by the controller (so that only the properties are
visible) or removed entirely to favor public functions (getSomething
()). Obviously this is quiet specific to the controller situation and
it is not a policy I would use everywhere.

* Ereg2 extends Ereg with no real advantages. Using new Ereg2() is
exactly the same as new Ereg() so I find it a bit pointless. Since it
shares just one static method, I would make it an helper class (not
extending anything) ... something like EregTools using haxe convention
for this type of class)

* indexPath seems a little broken to me. It works under certain
circumstances but not always. In my dev setup I have mod_rewrite
active and the project is not directly on the root (it is in "/
igniter"). Without changing the code I have been able to make it work
using the convention /igniter/index.n/whatever but this is less than
ideal. To make it work I have splited indexPath in 2 vars: basePath (/
igniter/) and baseProcessor (index.n); for now it works but I am quite
sure I have other things broken that I will have to fix sooner or
later

That's all for now,

Franco.

[Baluta Cristian]

i agree, i don't like the folder structure, i'd like that my files to be separated. i'm even not sure how to update the project, application folder already contains some files, do i have to replace them too?

--
Băluță Cristian
http://ralcr.com
http://imagin.ro

[Andreas Söderlund]

On Tue, Oct 20, 2009 at 11:48 AM, Franco Ponticelli <franco.p...@gmail.com> wrote:

Hello Group,
I've started using haxigniter and I wanted to share my first
impressions. Take them considering that I am still at the beginning of
learning it but I am not new to web development. So feel free to
ignore my thoughts if you don't like them ;)

Hello Franco, thank you very much for your valuable feedback. Haxigniter is definitely a work in progress, no official release has been made so this is just what is needed.
 

* Even if packaged as a haxelib, haxigniter doesn't fit the usual
philosphy for haxe libs. What I mean is that you cannot easily do -lib
haxigniter because you have to change files from the lib itself
(config, controllers ...). I understand that this is a totally
different approach (more symfony or ruby style for what I know) and I
am not saying it must be changed, I am just pointing it out

In the beginning, I basically took the best parts from Codeigniter, including the directory structure which works fine in a php application. I didn't care much that it's now a compiled, quite different environment. Still, the build tools and the dynamic nature of calling the controllers makes it a bit hard to create a pure library out of it. Suggestions are of course welcome if you see some way of doing it. (I can elaborate more on the issues if you like)

 

Also from an autocomplete point of view it
is annoying because you have a lot of duplicates available. In my
opinion those properties should be moved to an instance of a different
class accessed by the controller (so that only the properties are
visible) or removed entirely to favor public functions (getSomething
()). Obviously this is quiet specific to the controller situation and
it is not a policy I would use everywhere.

The Application class is holding all those properties, so removing the accessor methods and initializing them in the controller constructor could be the solution.
 

* Ereg2 extends Ereg with no real advantages. Using new Ereg2() is
exactly the same as new Ereg() so I find it a bit pointless. Since it
shares just one static method, I would make it an helper class (not
extending anything) ... something like EregTools using haxe convention
for this type of class)

I know, this was an early mistake that I didn't fix and forgot about. Having a single class in the haxigniter namespace is a bit annoying. I think I'll remove it altogether. Anyone using quoteMeta a lot? :)
 

* indexPath seems a little broken to me. It works under certain
circumstances but not always. In my dev setup I have mod_rewrite
active and the project is not directly on the root (it is in "/
igniter"). Without changing the code I have been able to make it work
using the convention /igniter/index.n/whatever but this is less than
ideal. To make it work I have splited indexPath in 2 vars: basePath (/
igniter/) and baseProcessor (index.n); for now it works but I am quite
sure I have other things broken that I will have to fix sooner or
later

It's very hard to detect the indexPath properly for all environments. It's not made easier by the fact that it's currently impossible to detect the web server document root on Neko. PHP has all sorts of useful stuff in the $_SERVER array that helps. Splitting the indexPath is a good idea, but it adds complexity. Can you send me a dump of your environment so I can take a look? Change the super(); call in application/Config.hx to super(true); to get the dump.

Again, thanks for your feedback. Anyone else got some comments about this?


/Andreas

[Franco Ponticelli]

In the beginning, I basically took the best parts from Codeigniter, including the directory structure which works fine in a php application. I didn't care much that it's now a compiled, quite different environment. Still, the build tools and the dynamic nature of calling the controllers makes it a bit hard to create a pure library out of it. Suggestions are of course welcome if you see some way of doing it. (I can elaborate more on the issues if you like)

Forcing the subclass of Application could be an option. So the developer should have to write its own main ... something like:

class MyApplication extends Application {
  static function main() {
    var app = new MyApplication();
    app.run();
  }
}

This should be the base but before run some useful things could be made:

app.config.controllersPackage = {
  default : "haxigniter.application.controllers", // this would reflect the current behavior but could be changed to an application specific package
  other : "myapp.controllers" // other could be the first segment of a URI, the following should be used as usual
}

Also the MyApplication file could be used to store the imports to the controllers.
 

The Application class is holding all those properties, so removing the accessor methods and initializing them in the controller constructor could be the solution.

I agree this could be a solution and coupled with the above anwser if Application (and others as well) could lose their status of singleton. Not a fan and I don't see the need in this context.
 

I know, this was an early mistake that I didn't fix and forgot about. Having a single class in the haxigniter namespace is a bit annoying. I think I'll remove it altogether. Anyone using quoteMeta a lot? :)

Why not moving it in a package like haxigniter.utils.EregTools ?

 

It's very hard to detect the indexPath properly for all environments. It's not made easier by the fact that it's currently impossible to detect the web server document root on Neko. PHP has all sorts of useful stuff in the $_SERVER array that helps. Splitting the indexPath is a good idea, but it adds complexity. Can you send me a dump of your environment so I can take a look? Change the super(); call in application/Config.hx to super(true); to get the dump.

I agree it is messy but a clean strategy must be found because the current requires hacks and it is not the best option. Follows the dump as requested.

Great work anyway, I am sure I can stole quite a lot :D

Franco

*** [2009-10-20 12:01:29] Start of dump

haXigniter configuration:

cachePath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/runtime/cache/'
logDateFormat: '%Y-%m-%d %H:%M:%S'
baseProcessor: 'index.n'
runtimePath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/runtime/'
defaultController: 'start'
logLevel: 'info'
applicationPath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/'
logPath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/runtime/logs/'
errorPage: 'null'
language: 'english'
basePath: '/igniter/'
permittedUriChars: 'a-z 0-9~%.:_-'
viewPath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/views/'
defaultAction: 'index'
error404Page: 'null'
sessionPath: 'D:/Projects/testigniter/bin/lib/haxigniter/application/runtime/session/'
development: 'true'
siteUrl: 'index.n'

haXe web environment (Neko):

getCwd(): 'D:/Projects/testigniter/bin/'
getHostName(): 'localhost'
getURI(): '/igniter/index.n'
getParamsString(): 'null'

Server environment:

OCAMLLIB: 'C:\Programmi\Objective Caml\lib'
VS90COMNTOOLS: 'C:\Programmi\Microsoft Visual Studio 9.0\Common7\Tools\'
CLASSPATH: '.;C:\Programmi\Java\jre6\lib\ext\QTJava.zip'
PROCESSOR_ARCHITECTURE: 'x86'
ComSpec: 'C:\WINDOWS\system32\cmd.exe'
USERPROFILE: 'C:\Documents and Settings\LocalService'
AP_PARENT_PID: '4308'
NUMBER_OF_PROCESSORS: '2'
PROCESSOR_LEVEL: '6'
QTJAVA: 'C:\Programmi\Java\jre6\lib\ext\QTJava.zip'
PROCESSOR_IDENTIFIER: 'x86 Family 6 Model 15 Stepping 6, GenuineIntel'
TEMP: 'C:\WINDOWS\TEMP'
MOD_NEKO: '2'
SystemDrive: 'C:'
TMP: 'C:\WINDOWS\TEMP'
CommonProgramFiles: 'C:\Programmi\File comuni'
COMPUTERNAME: 'KYRA'
FP_NO_HOST_CHECK: 'NO'
OS: 'Windows_NT'
PATHEXT: '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1'
windir: 'C:\WINDOWS'
Path: 'C:\Programmi\Mendeley Desktop;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;c:\Programmi\Microsoft SQL Server\90\Tools\binn\;C:\Programmi\Objective Caml\bin;C:\Programmi\Universal Extractor\bin;C:\Programmi\Motion-Twin\haxe\neko;D:\Projects\temploc;C:\Programmi\pgfconsole;C:\msys\1.0\bin;C:\Programmi\TortoiseHg;C:\Programmi\TortoiseSVN\bin;C:\WINDOWS\system32\WindowsPowerShell\v1.0;C:\Programmi\Universal Extractor;C:\Programmi\QuickTime\QTSystem\;C:\Programmi\TortoiseGit\bin'
ProgramFiles: 'C:\Programmi'
SystemRoot: 'C:\WINDOWS'
ALLUSERSPROFILE: 'C:\Documents and Settings\All Users'
PROCESSOR_REVISION: '0f06'

*** End of dump

[Andreas Söderlund]

Hello all, now I finally have some time to update haxigniter, I'm interested to know how we should take this project further? Responding to Francos ideas:

Forcing the subclass of Application could be an option. So the developer should have to write its own main ... something like:

class MyApplication extends Application {
  static function main() {
    var app = new MyApplication();
    app.run();
  }
}

I like this, and making haXigniter into a real library (for haxelib) is quite appealing. What would you guys prefer:

1. Some more coding when setting it up, like the subclassing of application, and having haxigniter as a library. Possibly a bit more work to build too.
2. Like it is now, a bit more difficult to update but easy to build and less code to make it run.
 

Why not moving it in a package like haxigniter.utils.EregTools ?

EReg2 is now haxigniter.libraries.ERegTools.
 

It's very hard to detect the indexPath properly for all environments. It's not made easier by the fact that it's currently impossible to detect the web server document root on Neko. PHP has all sorts of useful stuff in the $_SERVER array that helps. Splitting the indexPath is a good idea, but it adds complexity. Can you send me a dump of your environment so I can take a look? Change the super(); call in application/Config.hx to super(true); to get the dump.

I agree it is messy but a clean strategy must be found because the current requires hacks and it is not the best option. Follows the dump as requested.

In the current version (pushed to github but not released as a new version), it's finally fixed! config.indexPath and config.indexFile should take care of all problems.
 

Great work anyway, I am sure I can stole quite a lot :D

Haha, be my guest! Your feedback is very valuable.

/Andreas

[Franco Ponticelli]

1. Some more coding when setting it up, like the subclassing of application, and having haxigniter as a library. Possibly a bit more work to build too.

Obviously I amm all for this option ... this doesn't remove the opportunity to build tools to make life easier.

Franco.

[Andreas Söderlund]

On Fri, Nov 6, 2009 at 7:32 PM, Franco Ponticelli <franco.p...@gmail.com> wrote:

1. Some more coding when setting it up, like the subclassing of application, and having haxigniter as a library. Possibly a bit more work to build too.

Obviously I amm all for this option ... this doesn't remove the opportunity to build tools to make life easier.

I'm about to do some tests to see how it would work as a haxelib. I'm thinking something like this: Package the library as usual, then have a "run.n" that prompts for a project folder, then installs a basic project structure there.

Maybe the run.n could be the build and unit test tools as well? So it's all controlled with "haxelib run haxigniter [options]". Would be great not having to support two kinds of shell scripts...


/Andreas

[Franco Ponticelli]

I'm about to do some tests to see how it would work as a haxelib. I'm thinking something like this: Package the library as usual, then have a "run.n" that prompts for a project folder, then installs a basic project structure there.

Maybe the run.n could be the build and unit test tools as well? So it's all controlled with "haxelib run haxigniter [options]". Would be great not having to support two kinds of shell scripts...

Having a platform independent tool seems the best option and writing such tools in haXe/Neko is not really hard.

Franco.