Closed dcblogdev closed 8 years ago
@daveismyname First of all, congratulation for publishing of your new 3.0 beta tree!
So, will be named Nova, after all? So far, so good, and at a quick looking into code, I see that you adopted our routing, then I'm glad that, after all, some parts of our working was useful for The Greater Good.
Sure, I wonder why you cut off the named parameters support from the ClassicRouter, which is very useful for thingies like:
Route::get('login', 'users/login');
Route::get('logout', 'users/logout');
Route::get('archive/(:all)', 'blog/archive/$1');
But, after all, is a question about taste...
Still, let's talk about file serving (via routing).
Well, serving the files via routing is slow, a very slow thing with a huge impact about page loading.
This is one of the main reasons for why us we bypass the routing for certain paths and pass directly to file dispatching. If (in name of simplicity?), being even slower, you really want to serve the file via routes, then I suggest you to put the file serving route first of them, in the top.
In other hand, your actual design, which you suggest, will not work when the the site is installed into sub-directory.
Suppose that we install the Nova into http://localhost/framework. Then DIR should be framework/public_html, so this command (from nova/app/templates/default/header.php):
'resource'.Url::templatePath().'css/style.css'
will be expanded to:
resource/framework/public_html/templates/default/css/style.css
which is totally wrong, because the routing automatically adjust the path and expect:
framework/public_html/resource/templates/default/css/style.css
That's why the assets command, to be compatible with your routing, should be:
DIR . 'resource/' .relativeTemplatePath() .'css/style.css'
Lastly, but not for last, your file serving design have a huge security issue, demonstrated in the attached screenshot. Yep, your file serving is capable to dump any file from the application directory, including controllers or even models.
That's why the file serving should be activated only in certain paths, thing managed also by our pre-routing preg_match-ing, forcing those certain paths as accessible.
That's why us we "forced" the rule that the assets shall stay, well, into directories named assets, from modules and templates.
And, probably, some similar rules you should enforce too, if you don't want that epic security issue presented bellow.
All the best!
thanks for your feedback! it's really appreciated, OK that is a huge problem! I did try and get your style of routing working but never managed to get it working, I would appreciate any help with that if you would be so kind.
Regarding the classic routes I think I had that from an earlier version I had, I didn't spend a lot of time on that, named routes is better. I included it for the people who still want to use that style.
I opted to use your routing as its better, there a few parts I borrowed from you. Of course your credit remains.
Stopped php files from being served.
@daveismyname I will glad to help you on routing, but you should say where you want to arrive.
If you talk about file serving, is something like this: the preg_matches act as some fast routing, before the real routing, looking for pre-definited paths, then passing to real file serving from Response, the requested URI. In the same time, act as strong-hand limitation for the accessible files on file serve routing.
But, there should be some pre-definited paths available for file-serving. I.e. Modules/Blog/Assets/ or Templates/Default/Assets or whatever.
Then, what kind of problems you have with our routing?
Having the assets folder will be fine, I think the problem I had was exporting your code away from the classes it relied on the premis of the routes is great which is why i changed
@daveismyname If you want, I can prepare a pull request for porting the latest work on named and classic routing from 3.0-nova to the current tree, with no problems. The Routing is almost self-contained.
But, be aware that with some changes, it will serve files from Modules/[Module]/Assets/ , Templates/[Template]/Assets/ and assets/, then will do a strong-hand on the following paths, in the current tree:
nova/app/Modules/<Module>/Assets/
nova/app/Templates/<Template>/Assets/
nova/assets/
That will have some collateral consequences, as in that @jimgwhit will not have the ability to use javascript files random put into Views directory and will require to use a nova/app/Templates/Default directory instead of nova/app/templates/default one, without some additional changes.
Also, it use Doctrine Inflector to transform the paths. Yet, that is a very small package, rather much smaller than the Symfony's Console.
Ok I'm happy with that, worse case any user who wants random files can always place them in the public folder.
@daveismyname Okay, then. Tomorrow you'll have that.
working great thank you!
I haven't got time to go through anything in details tonight but will try and spend time on this over the weekend, but looks good!
I'll need to look at the new routing options for the groups can't remember the syntax etc for that.
Thanks again!
@daveismyname Thanks, but the changes was really minor, mostly about your paths name change and the namespaces!
BTW, just nitpicking about you README's description of Routing's file serving, to note that also are served the files from Assets directories placed into Modules...
ah yes! I'm going to expand on the readme to include more details.
@daveismyname Okay, then. I belive that now the new/beta Routing style integration is complete.
BUT, I believe also that right now the Assets Caching from Helpers\Assets is going nuts because those URI path transformations, and it should be adjusted too...
An idea to make quickly that Assets Caching working again is to transform the resource URIs paths into real URLs (prepending the site URL) and making no difference then, between remote and local resource files.
But, for that we should have available (and/or defined) the site URL. A collateral consequence of defining the site URL is that it make probably obsolete the DIR definition...
I think we leave the DIR as it is and have another one called SITEURL that contained the full http address that way bath can be used for different purposes.
@daveismyname A wise idea, keeping both of the two Worlds.
And that SITEURL should be added, in my opinion, into Url::resourcePath() and Url::templatePath(), instead of DIR.
@daveismyname But what we do with the its default value? Automatically guessed?
I talk about SITEURL.
I think that needs to be set as part of the initial setup when renaming config.php set the site add too I guess we could have some done in place to try and guess the url but keep it simply and enter one in so the default would be http://domain.com ?
@daveismyname For sure that value should be configured in the initial setup, instead of guessing.
And, no, about using http://domain.com by default, that will make the assets URLs to silently fail.
Then, in the documentation, we should strongly recommend/force the configuration of SITEURL...
@daveismyname OKay, then, I will implement the Config and URL helper part, using by default just http://www.novaframework.dev and I will leave for you the Assets helper changes.
OK great.
@daveismyname I saved the instructions for your first ver 3, does this part still apply?
more or less files are now inside a nova folder so to work from to have all files in public move the contents of nova into public_html then edit the paths in index.php:
define('APPDIR', 'app/');
define('SYSTEMDIR', 'system/');
define('PUBLICDIR', '');
define('ROOTDIR', '');
That should be it then it's the usual edit system/Core/Config.example.php and .htaccess as needed.
placing the files into nova folder is optional I did that so when my files are above the root they are grouped together. You can store them all in your public if you prefer.
The readme will be getting expanded on I have little time this week with work deadlines I had hoped it contained enough information to get started.
Hope I haven't missed anything the above post is somewhat confusion now with the edit.
@daveismyname The only important missing part is, in my opinion, where @jimgwhit started to worry about me already doing minor changes, which, in his opinion, will lead to a second (complicated) beta tree. Basically:
Don't get me wrong @LuckyCyborg , I appreciate you, but you are already doing minor changes. And that's what happened last time one change led to another.
Again, sorry for messing with @jimgwhit post. Maybe he will be kind to re-post it entirely.
ah I see, to be fair I asked for your help!
@daveismyname BTW, Dave, you use Url::templatePath() for another things than preparing assets paths?
Because,if it is used only for assets (after all, the templates are beyond webroot), will be nice to include, similar with Url::resourcePath() , the /assets/ part of URI, then instead to write:
Url::templatePath().'assets/css/style.css'
we have to write just:
Url::templatePath() .'css/style.css'
which will be similar with that Modules/Generic case:
Url::resourcePath() .'css/style.css'
Url::resourcePath('FileManager') .'css/style.css'
no I beleive it's only use is for linking to files within the templates.
@daveismyname Then you agree with this change in behavior?
PR incoming...
yes and merged.
@daveismyname
After all, I think that placing the framework's application and system into that nova directory is a bit unusual for the MVC frameworks, even for previous 2.2 users habit, then probably will create confusions, even from where they should do a "composer install".
For example, I bet that @jimgwhit still curse me, convinced that it was my idea... ;)
How about to move those directories: app, system & Co. into site root, in a more orthodox style?
After all, me and you we have no problems to manage in the actual style the framework, if it is the need. ;)
@LuckyCyborg I do not believe it is proper etiquette to change the words in my comment above. And no I do not want to be mean to anyone but you have to admit changes happened very fast before. I don't even have a chance to do any testing before a change was made. And since I can't Fork a tree I guess I'm not allowed it's hard to keep up with the changes. Right now I have to actually download, do composer all over again for every little change. If there is a way to Fork 3.0 please let me know I have tried every git command I know. That would make it so much easier too quickly stay up to date.
@jimgwhit How you are not allowed to "Fork" the tree?
As in your personal fork or as working local clone?
If you want a local clone:
git clone https://github.com/simple-mvc-framework/framework.git novadave
cd novadave
git checkout 3.0
git pull
Last command you have to execute every time when you want updates/sync with Dave's branch.
Sure, that works under Linux, but probably there is also git for Windows...
@daveismyname
After all, I think that placing the framework's application and system into that nova directory is a bit unusual for the MVC frameworks, even for previous 2.2 users habit, then probably will create confusions, even from where they should do a "composer install".
For example, I bet that @jimgwhit still curse me, convinced that it was my idea... ;)
How about to move those directories: app, system & Co. into site root, in a more orthodox style?
After all, me and you we have no problems to manage in the actual style the framework, if it is the need. ;)
OK let's put it out to everyone I prefer to put them files in a folder to stop them being mixed with existing folder above the document root, I don't see the issue in doing that.
So everyone please cast your vote here http://www.poll-maker.com/poll614714x7D474E86-25
Consider that if you're on a shared server placing files above the document root and not separating them into a folder to group them will make it difficult to know files files belong to the framework or even separating them per project should you have multiple domains using the framework.
@daveismyname Yes, that tree described in image is is exactly the style about what I talk. And let's not be fooled by the "nova" name of the folder... ;)
Consider that if you're on a shared server placing files above the document root and not separating them into a folder to group them will make it difficult to know files files belong to the framework or even separating them per project should you have multiple domains using the framework.
But is very simple. For example, we use multiple sites installation in Hostgator Shared, some having about 40 sites, everyone in that style. How we made to keep the framework bellow? Just make the Virtual Host associated with the site to point to webroot, i.e. public_html. Voilà!
Some other sites use a common /system, are installed in the follow style: the site(s) is enclosed into /apps/site_name while there is a number of webroots,i.e. /portal, /backend, /frontend, /api, etc.
In fact, having a boot file (aka index.php), where are defined the paths to application, system and eventually base path, is more than enough to do whatever combinations you want.
This works with CodeIgniter, Laravel, CakePHP, FuelPHP, you are afraid that will not work for Dave's Nova?
To understand that I don't make this suggestion for my use (I still will use 3.0-beta/3.0-nova branch if not using a major framework for something else), but I understand that this "nova" directory will create confusion and is a somewhat non-standard solution for a non-existent problem...
I know it will work just as it does now. The only difference in set up is removing nova from the paths so they become
define('APPDIR', dirname(__DIR__).'/app/');
define('SYSTEMDIR', dirname(__DIR__).'/system/');
define('PUBLICDIR', dirname(__FILE__).'/');
define('ROOTDIR', dirname(__DIR__).'/');
Either way will work takes a matter of seconds to change.
@daveismyname
I know it will work just as it does now. The only difference in set up is removing nova from the paths so they become
define('APPDIR', dirname(__DIR__).'/app/'); define('SYSTEMDIR', dirname(__DIR__).'/system/'); define('PUBLICDIR', dirname(__FILE__).'/'); define('ROOTDIR', dirname(__DIR__).'/');
Either way will work takes a matter of seconds to change.
Sure, for me or you is mater of seconds to configure that. But, I not sure how many other users will figure it in seconds.
Remember? You claimed to point your target audience to beginners. And why to burden them with another configuration step, while they do not really benefit from default configuration?
In other hand, if you and me, we want that style to configure for a particular site, it is matter of seconds to move the public_html out of framework and point a Virtual Host to that directory.
@daveismyname and @LuckyCyborg If you go back to the steps in your 2nd youtube video on the original 3.0 beta you had simple instructions on both techniques.
I'm hesitant to do videos if anything going to change, they then show the wrong instructions.
I'll update the instructions with the premise the nova folder remains (it's winning in the votes) that can be changed later if need be.
I'll add instructions for it's current use and how to use the less secure way under public.
@daveismyname I finally followed @LuckyCyborg instructions for pulling 3.0 to my local computer.
git clone https://github.com/simple-mvc-framework/framework.git novadave
cd novadave
git checkout 3.0
git pull But I can't seem to get it under my fork of 2.2 on github. Do you know the command I have searched and searched.
I've updated the install instructions to include both ways.
For the fork I would think it would have forked everything including the branches, so you should be able to go into the settings and changed the default branch from master to 3.0
@daveismyname Looking finally at your "poll" I laughed with tears!
Man, the Dark Side is strong with you!
Manipulating the people opinion with the folder's "nova" name? That's it?
That poll in fact have exactly zero value, because you don't explain clear about what is the proposed change, instead you are going slogan...
Come on! No offense, but then, for me, it is clear that you understand that that folder idea is ridiculous, after all. ;)
BTW, you tried to entry into Politics? You can be a good one in this field!
how is that manipulating? the folder is called nova I asked should 'nova' been removed as that's what it is called. I fail to see your point.
The folder has a use I've explained that multiple times now.
your last comment is very insulting please stop.
Hey @daveismyname I see you have been busy. I got all working good, in fact the only thing that's different for me, because remember I moved whats inside nova folder up right under htdocs. I just had to do this: In url helper
//return SITEURL .'templates/' .$template .'/assets/';
return SITEURL .'app/templates/' .$template .'/assets/';
As you can see I just added app here. Now as far as you know that one change, will it affect any thing else, because it works great. Please let me know what you think.
And again thank you for writing and maintaining a framework I enjoy.
Thanks and no you should be good to go.
very thank you .
i version 2.2 we can't route to other language like bellow
site.com ==default language site.com/fr ==other language
do i nova support a solution for routing language ??
another question :+1: do i can route to ultimate parameters to a controller
for example i have category nested and i version 2.2 we must define in router i need route all parameters like bellow
site.com/category/book/story/child/color
in
Yes languages can now be set by calling site.com/fr or site.com/de or site.com to load default language.
I don't understand your second question though.
@daveismyname Probably, he ask if the Routing supports now the optional parameters, i.e.
Router::any('admin/(:any)(/(:all))', 'App\Controllers\Demo@test');
And the response is: yes, the Routing support now the optional parameters.
But at first question, the response is that there is no support for localized content and switching language, similar with Laravel or CodeIgniter, who have a middleware for that. ;)
To be honest, you don't even adopted that simple Internationalization based in native PHP support, present into beta branch...
very thank you .
i version 2.2 we can't route to other language like bellow
site.com ==default language site.com/fr ==other language
do i nova support a solution for routing language ??
another question do i can route to ultimate parameters to a controller
for example i have category nested and i version 2.2 we must define in router i need route all parameters like bellow
site.com/category/book/story/child/color
in
As it stand the language changes I implemented were flawed, this has been put on hold until I have more time to look at it again, currently there isn't a way to change the language from the url.
@daveismyname Look into the following screenshot to see how behave the latest 3.0 RC1 in my installation. How about to revert all changes made to framework for implementing that language URI switching?
Looks like the things started there: https://github.com/simple-mvc-framework/framework/commit/5fcc5c6dffb6e63c50c7ac6bd75edd346ec37908
@daveismyname To note that there is still another error, showing into attached screenshot.
The Routing is nuts...
@daveismyname Okay, then. I fixed now the Routing.
PR incoming...
Hi I've just put in my 3.0 version in a 3.0 branch it's ready for testing I've added a readme with instructions.
It's not much different from 2.2 from a install perspective but once major change is the vendor folder is not included so composer must be used to install the framework.
All files now live above the document root apart from a .htaccess and index.php file the paths can be updated from there if you want all files to live in a single directory.
https://github.com/simple-mvc-framework/framework/tree/3.0