From ea0cedb3dad5327254f94c09929350ebfabf6075 Mon Sep 17 00:00:00 2001 From: Ingo Schommer Date: Thu, 21 Mar 2013 12:44:34 +0100 Subject: [PATCH] Removed internal/outdated/speculative docs from requirements.md --- docs/en/reference/requirements.md | 58 ------------------------------- 1 file changed, 58 deletions(-) diff --git a/docs/en/reference/requirements.md b/docs/en/reference/requirements.md index 5e138beae..c69c1cf7a 100644 --- a/docs/en/reference/requirements.md +++ b/docs/en/reference/requirements.md @@ -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]` \ No newline at end of file