I want to create a custom ./config/unavailable.php page using the layouts and styling used by the rest of my application. I could just copy the generated HTML that one of these pages renders, but then if I ever change the layout or style I would have to re-copy.
How can I render the unavailable.php page the same way I render the views?
I am using symfony 1.4.
unavailable.php is called when symfony is busy clearing its cache. You might want not to disturb it too much at this moment, that's why plain php is used. Copying html could be done by a cron task though, so if I were you I would try to combine cron, wget and sed to achieve this.
I'd suggest keeping it as manual HTML, a simple page. Whatever you need to do to copy over layouts/templates (which contain stuff that Symfony needs to execute to generate) isn't worth unless you plan having your app unavailable for most of the time. It's just easier to copy things over manually if you ever decide to make big CSS changes.
Related
I am new to Liferay, and I still don't know the difference between the various 'kind' of Liferays.
This Liferay is what I am talking about.
I understand that you have to create a page first, and then add components (fragments) in it.
I also understand that you can go to fragments, and create a custom fragment with a custom CSS, and then import it into your page.
However, what I want to do is have a global CSS that I can use for all fragments inside a page, rather than having to add CSS for each fragment.
Is that possible, and if so, how?
I know I can use the 'style-books' which apply to an entire page, however, I don't know how to customize them, and it doesn't seem that that's even possible.
To avoid coding, you can use the css additional textbox provide by theme settings.
It's a whole page css addon for every pages in the site
In manifest.json, we specify our background page and can put an html or a js file for it. Since it is only a script that executes what sense does it make to have an html file for it?
I mean where is UI going to get shown anyway?
Similarly the devtools_page property has to be an html file. What sense does that make?
It will not be shown anywhere (that's the essence of "background"), but some elements on it make sense.
You can have an <audio> tag, and if you play it, it will be heard.
You can have an <iframe> with some other page loaded invisibly.
..and so on
As for devtools_page, it would actually be visible in the interface (as an extra panel in the DevTools)
It is possible that devtools_page must be an HTML file just for legacy reasons: it was not updated when manifest version 2 rolled out with changes to how background pages are specified. Still, the same arguments as above apply.
background_page is a legacy feature from the initial support of extensions in Chrome. background.scripts was added in Chrome 18. I can't speak for Google's original intentions but I'd guess that in the original design using an page felt more natural and would be less likely to confuse developers. Once they realized how many background_pages were just being used to load JavaScript it made sense to explicitly support that.
I'm using Bootstrap files within my application and I want to enable "Use runtime optimized JavaScript and CSS resources".
the problem I have is once enabled; glyphicons-halflings-regular.eot, glyphicons-halflings-regular.svg and glyphicons-halflings-regular.woff cannot be found:
I know for Bootstrap 2.3 we could use a Theme that loads a .CSS file that changes relative locations as described here http://www.bootstrap4xpages.com/bs4xp/site.nsf/article.xsp?documentId=F435B6DC54486B67C1257B6B002E5A6C&action=openDocument
So, what should I do to handle relative locations with Bootstrap 3?
You have to tweak the path to the web font resoureces in the Bootstrap CSS files.
Delete the part with "../" and replace it with the relative path to the font files within your project structure, e.g.
bootstrap/fonts/...
Then aggregation will load the fonts correctly.
This does not answer your question but if you want to use Bootstrap 3 you'd be MUCH better off using the Boostrap4Xpages project on OpenNTF.org. It will perform better and the resource aggregation will work better. It's easy to install and use but it is a plugin on the sever so that needs to be done. It's not self contained to the NSF. Try and move to this if at all possible.
Regarding the actual question. I'm not sure I know the answer specifically. I do know that using relative links can sometimes be a problem if the browser's URL doesn't have the page.xsp portion. So it works on the page.xsp and NOT the default launch XPage where the URL ends with the database.nsf. What I've done in the past there is set the application to launch to something like "start.xsp" and in that page in beforePageLoad to a redirect to "home.xsp". This forces the browser url to always show the page name and made life a little easier when dealing with adding projects to WebContent.
I want to be able to dynamically reference JavaScript and Stylesheets depending on which page a user is on in Express. I thinking the best way to do so (though I'm open to suggestions) is to pass the current view to the layout page.
For example;
Given the url http://example.com/trees
I would want to have some logic in layout.jade that said something to the effect of:
script(src="/javascripts/{view}.js")
Which would get rendered as:
<script src="/javascripts/trees.js"></script>
Any suggestions or best practices for doing this?
req.route is the matched route, so things like req.route.path etc are available, or of course req.url which may be parsed. With express 2x you can expose these values to views automatically using "dynamic helpers" or res.local()
There are no best practices for doing this, since Express doesn't provide Rails like url helpers, so I think you're approach is fine.
The easy answer is to just put ALL your javascript into a single file and be done with it. Ditto for CSS. See the Ruby on Rails asset pipeline for details. You are probably making your life more complicated than necessary and also less efficient by having different javascripts on different pages.
However, since you asked, the answer for javascripts is easy. Just put the extra <script> tags in the view, not the layout. Problem solved. CSS doesn't work as cleanly because the <link> tags need to be inside the <head>. In this case, I define the styles I need as an array of strings and loop over that in my layout template. So in my route I set up a local variable such as
locals.css = ['/css/one.css', '/css/two.css']
Then just loop over that in your template and generate one <link> tag for each.
I often see that websites use more than one page to display their information, while I've always preferred to use a single page which automatically changes its content by means of a PHP script.. Won't it be faster and simpler to have only one page that changes every time using a webpage argument, instead of having multiple copies of the same layout?
For instance:
... <body> ... <?php insert_requested_content(); ?> ... </body> ...
should be simpler than having a bunch of pages with the same header, footer, navbar, etc..
When I create a website, I usually have one index.php page and then the content pages, which are included into the index.php by the script, when they are requested by an argument such as:
http://mywebsite.com/?content=news
So: why people still use many different pages? Is there any particular need of doing this, or it's just a matter of choice?
Do spiders encounter any difficulties when trying to access the content of a website created with this design?
Your program structure is usually made easier by having multiple pages to reflect your different content while maintaining a common header/footer and css that can be inserted as you stated above. Placing all of your content in one page and dynamically trying to determine what the user is requesting and display it properly can become a nightmare of if/else statements if your site gets much more than three or four pages of content.