Directory structure

Hello guys. What are you thinking about default yii directory structure. Will it be the same?

You mean one that’s generated by yiic webapp? Last time we’ve discussed it the decision was to provide multiple bootstrap directory structures.

Yes, that’s what I’m talking about. I think a lot of developers are using directory structure generated by yiic. Have you decide which options to provide?

Preliminarily it was decided that yiic webapp will be able to generate multiple bootstrap types. At least one of these will be pretty much the same as it is.

Hi,

I apologize, but it is not quite clear to me, what is meant by "multiple bootstrap types"?

Does that mean that I can choose generated site structure?

Or perhaps what type of webapp shall be generated?

Problem has been discussed also here:

http://www.yiiframework.com/forum/index.php?/topic/20786-refactor-site-structure-to-reflect-real-website/page__view__findpost__p__101871


Also my question:

Currently the extension "giix" implements advanced features for generating webapp. Would you consider moving such extension into Gii module?

Thanx

Lubos

multiple bootstrap types = webapp types.

giix won’t generate the application. You still need to run yiic webapp in the console to generate the application.

giix will generate model and crud files for an existing application.

Right, of course, sorry for typo.

Yet, my previous question remains unanswered - some extensions are better than the ones supplied along with the framework Yii 1.X. For example giix or captcha-extended, that I wrote after the original Yii captcha was broken after 2 days by spammers.

So my original question is - Is there a plan to move some improved extensions into Yii 2.0 core?

I believe that would be quite beneficial for the framework.

Cheers

Lubos

We have to maintain backwards compatibility but since we’ll push Yii2 alpha to GitHub you’ll have a chance to get your changes into the core before first stable release.

Hi,

It is good that you will be moving yii2 to github. I also like the idea of generating multi bootstrap…

With gii, we can extend/customise templates for model etc.

[b]

[/b]

Will you be supporting the ability to extend of customise what is generated for the types of webapp and the directory structure that can be generated?

I guess that what you mean by ‘multiple’ bootstrap types is ‘pluggable’ ?

Meaning that it’s going to be easier to plug your own custom bootstrap into the yiic webapp generator?

That’s one of the missing links in Yii IMO.

I usually copy the cli/views/webapp dir and the webapp command and make that my own.

But I feel dirty when I mess around with the framework itself. :)

[s]I haven’t looked deeply into this, but it seems that Yii requires that the entire “themes” directory to be under the webroot.

It would be nice if we could separate it and have a "themes/themename/views" anywhere and "themes/themename/{images,js,css}" under the webroot.[/s]

EDIT: Totally overlooked CThemeManager::basePath.

@mentel: but everything has still to be web-accessible?!

I’m not sure I understand your question, but I’ll try to answer it.

The files in “themes/themename/views” don’t have to (and shouldn’t) be Web-accesible. They shouldn’t be under a public directory (webroot). You can leave this directory under “protected” or anywhere else, outside of your public directory.

The directories "themes/themename/{images,js,css}" contain stylesheet, javascript and image files. Those need to be under a public directory.

What I wondered about is, how does CThemeManager::basePath affects the separation of view files and CSS, JS, images?

Furthermore, CThemeManager::basePath has to be a web-accessible directory - right? The only way to protect your views is a .htaccess file. And I found no CThemeManager::viewPath or something.

I hope this explains my initial question a bit better.

schmunk,

There’s a CThemeManager::baseUrl that deals with the URL of the Web-acessible components of the theme (images, stylesheets, javascript etc).

Since CThemeManager::baseUrl is independent of (and isn’t changed when you change) CThemeManager::basePath, you can achieve the separation of the private and the public files.

Thus, CThemeManager::basePath is equivalent to your "CThemeManager::viewPath".

I advise against using a .htaccess file to avoid access to your private files. Someday it can go wrong. It’s better to remove the private files from your public directories.

Thank you very much for your explanations.

I would not have understood the docs in that way, I thought they have to point to the same directory.

But, if a theme is an installable item in your application, it makes sense to keep all associated files together. Web designers for opensource and commercial applications usally provide theme packages based on a standard directory structure partially controlled by application conventions. Some .htaccess protection of the theme directory and including an empty index.htm in the other directories (css/, images/, js/) should suffice for most applications. Unless you know something I don’t know which is certainly possible.

I use a modified implementation of Qiang’s application structure for large applications with an added www/ directory at the same level as admin/, console/, common/, and public/. This allowed the latter four directories to remain protected using the original protected .htaccess. www/ is web accessible and structured as so:




/admin/

/common/

/console/

/public/

/www/

        admin/

            images/

            themes/

               classic/

                   css/

                       layout.css

                       style.css

                       index.htm

                   images/

                       logo.png

                       index.htm

                   js/

                       classic.js

                       index.htm

                   views/

                       index.htm (also for all view subdirectories)

                   classic.tpl

                   classic.png

                   index.htm

             .htaccess

             index.php

        public/

            images/

            themes/

               classic/

                   css/

                   images/

                   js/

                   views/

                   classic.tpl

                   classic.png

             .htaccess

             index.php

Most of my applications are intermediate to large in size and above works fine for me. The above is very extensible if I need to add other application beyond admin and public (e.g., subdomains).

Yes. I have thought of it, too.

But in this case CAssetManager may help.

This is called Security through obscurity. Not recommended to rely on that.