3.0 beta is now ready for testing

[dcblogdev]

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

[woodsy1]

Is the new routing faster in serving assets then the old one? I have noticed that my pages load pretty slowly once I moved to 2.2 from custom php where it all loaded pretty fast.

[LuckyCyborg]

@woodsy1 Sorry, but I'm not sure if I understand right your question.

You ask about what old routing, as comparative?

To note that v2.2 do not have support for serving assets.

The first one which is capable to serve assets (and to work with the framework above to webroot) is our beta design.

And the actual 3.0 RC1 use (literally) our Routing, then the performances are the same.

In other hand, the assets serving via Routing have a performance impact, then is safe to assume that the current version is slower than 2.2 where you (are forced to) use directly the assets deployment.

[jimgwhit]

@daveismyname well after testing for a few days I found that I can use

<link href="<?php echo Helpers\Url::resourcePath(); ?>css/style.css" rel="stylesheet">

As opposed to

<link href="<?php echo Helpers\Url::templatePath(); ?>css/style.css" rel="stylesheet">

Which enables me to leave the url.php file un-changed, this does work better
moving css and js file under the main assets folder rather than the one under
Templates/Default/Assets. Which brings up a question, why two possible places for assets?
Wouldn't it be better to just have the main assets folder located at
whateversitename/nova/assets? Or in my case, I moved files up from nova so it would be
whateversitename/assets.
Like I said moving css and js files here works for all combinations of framework usage. And make it less confusing as to where to store the js and css files. Of course the header and footer files would remain where they are.

[dcblogdev]

Glad you are sorted with that, the reason for the 2 places is the assets folder will be for anything you need available music files/attachments/images etc and the assets folder within each template for images/js/css specific to that template.

This way allows to server both cases, in your case in makes no difference as all your files will be in the public folder so you can run them from anywhere without any extra work needed.

[jimgwhit]

@daveismyname while you are there can you read over the closed issue #633 and give your thoughts? I can work that out, but you will see from the reading what I mean.

[dcblogdev]

OK I'll need to look at that on a windows machine to be able to answer with any certainty, I'll do that soon.

[LuckyCyborg]

@jimgwhit

well after testing for a few days I found that I can use

<link href="<?php echo Helpers\Url::resourcePath(); ?>css/style.css" rel="stylesheet">

As opposed to

<link href="<?php echo Helpers\Url::templatePath(); ?>css/style.css" rel="stylesheet">

Well, there is a difference between. Calling Helpers\Url::resourcePath('ShinyOne') will return:

http://www.yoursite.com/modules/shiny_one/assets/

While calling Helpers\Url::templatePath('ShinyOne') will return:

http://www.yoursite.com/templates/shiny_one/assets/

To note that both method transform the argument into lower_snake_case, thing that the Routing understand and it is able to transform the path back.

So, for:

http://www.yoursite.com/templates/shiny_one/assets/css/style.css

The Routing will expect to find the file into:

nova/app/Templates/ShinyOne/Assets/css/style.css

[jimgwhit]

@LuckyCyborg calling

<link href="<?php echo Helpers\Url::resourcePath(); ?>css/style.css" rel="stylesheet">

With no arguments loads

mysite/assets/css/style.css

And works perfect.

[LuckyCyborg]

@jimgwhit Sure, because that is the alternative usage of Url::resourcePath()

Without arguments, it give you the URL path to the (Generic) Assets.

[jimgwhit]

@LuckyCyborg and that is exactly what I wanted all along an easy way to load css, js files without being forced into using assets.php. I like loading the regular way as described above. So all is well with this.

[jimgwhit]

@daveismyname referring again to issue #633 I see how you did it. After a re-study of dirname in the php manual, it gets a parent dir. So you are saying:

define('APPDIR', dirname(__DIR__).'/nova/app/');

Go up then go to nova.
Whereas

 __DIR__ 

alone acts on the dir it's called from. So it's no big deal for me to simply:

define('APPDIR', dirname(__DIR__).'/mysite/app/');

In essence it's the same thing, I'm just not using nova as explained before.
Sorry for this confusion, but resolving paths has always been tricky for me. You and @LuckyCyborg could figure it out in a second. Hi hi.
One more thing, I have noticed in testing that 3.0 seems to take a hair longer to load than 2.2. I don't know why. But pagination is just as fast.

[AdminUI]

Ive got version 3 setup with the 'nova' folder below root. Im getting issues trying to get any images within the template/default/assets/images to show on any page. Also style sheets appear to be loading as firebug is not throwing up a not found error. But no styles are working. If i view source on firefox and click on the style sheet I am getting a Fatal Error: <b>Fatal error</b>: Call to undefined function finfo_open() in <b>/home/newbike/nova/system/Helpers/Response.php</b> on line <b>166</b><br /> Maybe this is why my images are not showing also? I have setup on cpanel vps server running php 5.6. Any Suggestions?

[AdminUI]

Ok forget that, I have just been through the apache setup and finfo was not enabled. I am rebuilding apache on the VPS now and will try again. I will post the results back later.

[AdminUI]

All working well again now. Maybe finfo_open should be stated as a requirement to run the 3.0 framework. Im sure its not standard on cpanel servers and has to be enabled.

[LuckyCyborg]

@southcoastweb First of all cPanel is a Web Management Interface, not an Operating System. That Operating System can be (usually) CentoOS or even Ubuntu Server.

In other hand, I'm pretty sure that finfo_open work like a charm under usual server operating systems like those enumerated.

[AdminUI]

@LuckyCyborg , I know cpanel is not an operating system and have nt stated it was. i was just letting you know it was nt setup on a local machine using mamp or wamp. What i was trying to state is : I have checked several VPS now from various providers that have cpanel installed on CentOS and only 1 of those had finfo_open installed. The others would need it adding to the server configuration to make the framework work correctly. As this is an RC release that was not live I was only asking a question if it should be stated that finfo_open is a requirement for the framework to function correctly. i guess you dont feel that its an issue but when people are coming back saying the framework is not working, rather than add a line to the readme that it states it is a requirement.

Apart from that i love this framework and appreciate the hard work, @daveismyname , you and many others have put into it.

[jimgwhit]

@LuckyCyborg and @daveismyname and @southcoastweb what in the framework relies on finfo_open? Please let me know specifics.

[AdminUI]

@jimgwhit , Morning it is used in the Helpers > Response > serveFile class on line 166 is the first instance. Without it any css/images/js served from within the assets folder do not work if used above the public_html folder. It is however very clever how it works once it is working.

[dcblogdev]

I've been doing more tests and trying nova on a server where I haven't enabled finfo_open yet, I've commented out the code in the helper and have css and images loading above the doc root, they are loading fine.

I'm curious if that's needed after all.

[dcblogdev]

I've been thinking the routes should be in the app folder rather than the system folder as they will be accessed often, the same applies to language files.

Are there any objections to changing the structure to this?

[AdminUI]

I think there are advantages to the finfo_open and some disadvantages. Its nice when you have an admin template and site template running, because the css and images are stored in their template assets folder, and shared css and images, ie logo files, reset css, animate.css in the main assets folder outside of the template. Thats how i currently have a test setup. Disadvantage is like me yesterday i could nt get anything to work until i figured out it was nt enabled on the server. I have access to server setup so i could easily enable finfo_open , but some people on shared hosting will not have the flexibility to do this and this may drive them away from the framework.

files in the public_html do not also look like they are attached to a framework driven site as they are simply in /css or /images if you view the page source. Whereas if they are in the templates folders they are in /templates/default/assets/css

I cant see a security risk if images js and css are served from within the public_html folder. This im guessing will mean the assets helper will need to be altered or maybe somehow have a classic and a new assets helper.

[dcblogdev]

I've running a copy of nova on a live server, the image is coming from nova/assets and css is coming from nova/Templates/Default/Assets/css/

both are loading normally. without using finfo. running static elements like those under the public won't cause any problems as far as I can see.

[jimgwhit]

@daveismyname your latest update on index.php you have for example app (all that way)

define('APPDIR', realpath(__DIR__.'/../nova/app/').'/');

Last "/" needs to be removed, or am I not seeing something. Also would

define('APPDIR', realpath(__DIR__) . '/../nova/app/';

be better, or does that work differently, haven't tested yet, been busy.
Also @southcoastweb I don't use assets, response.php, I load my css and js the old fashsioned way like

<link href="<?php echo Helpers\Url::resourcePath(); ?>css/style.css" rel="stylesheet">

And I don't use hooks, I don't even know what hooks are. The first thing I do is start commenting out stuff I won't use. Same in a laravel site I did a while back, loaded css and js in the regular way. I like to have control, not a class or function I totally don't understand.. But I've only been doing this stuff for 30 years.

[dcblogdev]

I've been trying our nova on the root and on a sub folder the paths I used work better then I had and meant less needed changing with in the sub directory.

the last / was needed at least in my case it was. Having the ../ after the DIR don't take effect so they need to be within the realpath, I'm hoping that would make the paths more consistent even across windows.

When I ran this on Windows 7 works the same as on my Mac/Linux.

[jimgwhit]

@daveismyname I am talking about here

app/').'/');

You have a "/" after app then another, this doesn't cause an error? On tablet now not main, can't test now, not till tomorrow.

[dcblogdev]

Off the comp now but I'm sure it returns without the trailing slash so I needed to add it back on.

On Monday, 21 March 2016, jimgwhit notifications@github.com wrote:

@daveismyname https://github.com/daveismyname I am talking about here

app/').'/');

You have a "/" after app then another, this doesn't cause an error? On tablet now not main, can't test now, not till tomorrow.

— You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub https://github.com/simple-mvc-framework/framework/issues/619#issuecomment-199066388

Warmest Regards.

DAVID CARR Web Developer

Email: dave@daveismyname.com website: www.daveismyname.com website: www.simplemvcframework.com http://www.simplemvcframework.com Mobile: 07429 561 809

[AdminUI]

@jimgwhit , im with you on that one. I have moved my v3 test sites css, images and js within the public_html folder. Its working perfectly that way. I do like the idea of modules as it makes it easy to just pick a module up and place it into another project. Which is the only time I use the hooks. I load certain jquery plugins into certain pages using a $data['plugins'] and also a $data['css'] variable within my controller and then pushing that to a $js array in the footer and a $css array in the header and then loaded using the assets helper. Not sure if its the best way but it makes it very manageable. e.g:

$css = array(
    '//maxcdn.bootstrapcdn.com/bootstrap/3.3.4/css/bootstrap.min.css',
    '//maxcdn.bootstrapcdn.com/font-awesome/4.5.0/css/font-awesome.min.css',
    '//fonts.googleapis.com/css?family=Questrial',
    DIR . 'css/animate/animate.min.css'
);
if(is_array($data['css'])){
    foreach ($data['css'] as $key => $value) {
        array_push($css, DIR.$value.'.css');
    }
}
array_push($css, DIR.'css/styles.css');
Assets::css($css);

And if i need page specific javscript i use a $data['js'] and just echo it within a <script> tag. But i am going to steer away from the response helper for the time being.

30 years.. sounds like you started on a zx spectrum, I was telling the boys in the office about loading programs in via audio tape and they could nt believe it..

[jimgwhit]

@southcoastweb my first database experience was dBASE 3 the computer booted from a floppy disk. This is before Windows even existed.

[LuckyCyborg]

@daveismyname The finfo(_open) is used to detect the right mimetype of the served file. Which can be tricky (like can be seen in the code, where I do also some strong-hand) and it is not only about JS and CSS files...

That right mimetype is very important for having a correct file manipulation by web-browsers. For example, for loading a FLV file in a IFRAME, etc.

I strongly recommend to leave that code as it is, other solutions being able to introduce subtle issues into file serving, thing well tested and demonstrated for us.

In other hand, look like is a logical and wise decision to move Config.php, routes.php and Languages into App. Another argument for that is the ability to create multi-tenant applications using only one system folder. In fact, the multi-tenant applications is also an argument against preserving everything into "nova" folder, but, whatever.

Also, note that moving the logs folder also into App folder is a good idea, considering a multi-tenant applications.

BTW, multi-tenant applications are applications which use a common framework (e.g. system folder), and usually can be structured into frontend, backend and api.

[LuckyCyborg]

@daveismyname Commenting into your pull-request 2e39e201792629c88ffa6d654536e882ea73bd56

What is the sense to make the templatePath and relativeTemplatePath, let's say, "flexible" ?

To note that those "Assets" folder names are well known names used into pre-routing preg_match-es to detect the assets folders into URI. Should be read: they are hard-coded.

If you change the Assets folder name when calling the templatePath utilities, the epic result is that those paths are not recognized by routing and file serving will fail.

Then to change those folder names will require to change also the Core\Router according, then I consider an idea prone for errors. Remember? It's about a very simple framework, very simple to configure too.

In other hand, everyone who need a "non-standard" solution can alwasy put the asset files directly into public_html (sub-folders) and they will be served as is, without Routing intervention.

[dcblogdev]

I strongly recommend to leave that code as it is, other solutions being able to introduce subtle issues into file serving, thing well tested and demonstrated for us.

Agreed.

Also, note that moving the logs folder also into App folder is a good idea, considering a multi-tenant applications.

Yes I can see the login in that.

To note that those "Assets" folder names are well known names used into pre-routing preg_match-es to detect the assets folders into URI. Should be read: they are hard-coded.

As these are helper functions they won't always be used for routing, in my cms I use them to scan theme folders I didn't need to use the Assets in that case as I was not routing but scanning.

This way the default when used for routing remains the same.

[LuckyCyborg]

@daveismyname

As these are helper functions they won't always be used for routing, in my cms I use them to scan theme folders I didn't need to use the Assets in that case as I was not routing but scanning.

This way the default when used for routing remains the same.

From this POV, yes, make sense, but probably only relativeTemplatePath can be useful beyond the routing because templatePath return the full url to assets folder. E.g.

http://www.novaframework.dev/templates/default/assets/

So, the ability to be "flexible" is questionable. What you want to serve also? Directly PHP files?

[dcblogdev]

In that specific case yes it was but it could easily be other file types.

[LuckyCyborg]

@daveismyname Yes, it could easily be other file types, but those will not be recognized by Routing and served as asset files; and every other file used into framework is a php one, even is a template fragment (e.g. header.php).

Also, those file will not be available via their URL. Simply put, this URL will be ignored/non-recognized by the framework, both by routing and by controllers:

http://www.novaframework.dev/templates/default/pages/shinypage.html

[dcblogdev]

I was not using it for routing at all.

[LuckyCyborg]

@daveismyname Sure, I understand that.

But, templatePath return an (absolute) URL not a absolute or relative file path.

Also, this absolute URL contains a properly transformed path, able to be processed back by Routing. E.g. for the real path:

/home/dave/sites/nova/app/Templates/ShinyTemplate/pages/

You will have, via templatePath('ShinyTemplate', '/pages/'):

http://www.novaframework.dev/templates/shiny_template/pages/

This URL path can be understand (only) by the Routing, I believe...

[jimgwhit]

@LuckyCyborg help. Earlier you gave these instruction to setup branch 3.0 on my computer

git clone https://github.com/simple-mvc-framework/framework.git novadave
cd novadave
git checkout 3.0
git pull

It worked great. Now the funny thing, sometimes from novadave folder to update I can do

git checkout 3.0
git pull

And it works. But other times it doesn't, I get conflict errors and I have to:

git reset --hard

What's really crazy is after the git reset --hard all files in novadave folder has the current date. But when I do

git push --all --repo=https://github.com/jimgwhit/framework.git

It properly updates my fork / branch 3.0 but has correct dates.
I have tried many git commands to do this correctly, what are the correct commands to keep a fork updated correctly? I have had no problems with main fork, just the branch.

[LuckyCyborg]

@jimgwhit To be honest, I'm not a git Guru...

Maybe someone can help you better in that problem.

[dcblogdev]

I'm not either, I plan on releasing 3.0 this weekend so it won't be a problem for much longer.

[LuckyCyborg]

@daveismyname Then, considering the actual situation, I guess that I can consider the branch 3.0-nova as my standalone Personal Project, and to apply any changes I would like/need, even if them break the backward compatibility with the SMVC in 2.2 incarnation, right?

[dcblogdev]

Yes yours to do with as you see fit.

[LuckyCyborg]

@daveismyname Thanks.

BTW, please look on my latest PR for branch 3.0, which contains a final touch to Routing for release.

I tried to improve/consolidate the Routing (imported) into 3.0 branch in the same time when I continue my development in my own branch.