tonyair/silverstripe-framework
1
0
Fork 0
mirror of https://github.com/silverstripe/silverstripe-framework synced 2024-10-22 14:05:37 +02:00
Code Issues Projects Releases Wiki Activity

Removed internal/outdated/speculative docs from requirements.md

Browse Source
This commit is contained in:
Ingo Schommer 2013-03-21 12:44:34 +01:00
parent 2787d360c1
commit ea0cedb3da
1 changed files with 0 additions and 58 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

58
docs/en/reference/requirements.md
View File

@ -124,63 +124,5 @@ In your controller's init() function, add:
:::php
Requirements::set_write_js_to_body(false);
## CMS Requirements
The SilverStripe core includes a lot of Requirements by itself. Most of these are collated in `[api:LeftAndMain]` first.
## Motivation
Every page requested is made up of a number of parts, and many of those parts require their own CSS or JavaScript.
Rather than force the developer to put all of those requests into the template, or the header function, you can
reference required files anywhere in your application.
This lets you create very modular units of PHP+JavaScript+CSS, which a powerful concept but must be managed carefully.
## Managing Generic CSS styling
One of the aims of this is to create units of functionality that can be reasonably easily deployed as-is, while still
giving developers the option to customise them. The logical solution to this is to create 'generic' CSS to be applied
to these things. However, we must take great care to keep the CSS selectors very nonspecific. This precludes us from
adding any CSS that would "override customisations" in the form - for example, resetting the width of a field where 100%
width isn't appropriate.
Another solution would be to include some "generic CSS" for form elements at the very high level, so that fixed widths
on forms were applied to the generic form, and could therefore be overridden by a field's generic stylesheet. Similar
to this is mandating the use of "form div.field input" to style form input tags, whether it's a generic form or a custom
one.
Perhaps we could make use of a Requirements::disallowCSS() function, with which we could prevent the standard CSS from
being included in situations where it caused problems. But the complexity could potentially balloon, and really, it's a
bit of an admission of defeat - we shouldn't need to have to do this if our generic CSS was well-designed.
## Ideas/Problems
### Ajax
The whole "include it when you need it" thing shows some weaknesses in areas such as the CMS, where Ajax is used to load
in large pieces of the application, which potentially require more CSS and JavaScript to be included. At this stage,
the only workaround is to ensure that everything you might need is included on the first page-load.
One idea is to mention the CSS and JavaScript which should be included in the header of the Ajax response, so that the
client can load up those scripts and stylesheets upon completion of the Ajax request. This could be coded quite
cleanly, but for best results we'd want to extend prototype.js with our own changes to their Ajax system, so that every
script had consistent support for this.
### Lots of files
Because everything's quite modular, it's easy to end up with a large number of small CSS and JavaScript files. This has
problems with download time, and potentially maintainability.
We don't have any easy answers here, but here are some ideas:
* Merging the required files into a single download on the server. The flip side of this is that if every page has a
slightly different JS/CSS requirements, the whole lot will be refetched.
* Better: "Tagging" each required file for different use-cases, and creating a small set of common functionalities
(e.g. everything tagged "base" such as prototype.js would always be included)
* Do lazy fetching of scripts within an ajax-call. This seems to be possible, but very tricky due to the asynchronous
nature of an ajax-request. Needs some more research
## API Documentation
`[api:Requirements]`