I was reviewing some code and it had these map references but they
were of the format:
mapName.THIS_KEY
mapName.ANOTHER_KEY
Then I googled and saw that:
"Finally, the dot operator and the bracket operator are somewhat
interchangeable. For example, ${user["firstName"]} could also be used
to retrieve the firstName property of the user object, just as
${commands.dir} could be used to fetch the value associated with the
"dir" key in the commands map."
REF: http://www.ibm.com/developerworks/java/library/j-jstl0211/index.html
I can see why, because it allows multi-dimensional maps to be
referenced like this:
mapName.ANOTHER_KEY.SOMEKEY_INSIDE_THAT_INSIDE_MAP
and won't go Boom! when the ANOTHER_KEY lookup returns nothing.
I still find it kinda icky. I think the dot expression should really
be used sparingly.
If you're doing lookups only one level deep, then it is so much easier
to understand when you do map lookups the same way you do it in normal
Java code.
Thursday, 29 November 2012
Thursday, 22 November 2012
"Print this page" functionality using jQuery - opening a print-friendly page
Certain pages on my current project have either a 'Print', or both
'Print' and 'Email' icons.
The implementation in the old system works like this:
- user clicks on Print icon, triggering a javascript request
- request includes the portlet Id and content Id as a parameter,
opening a new page
- the new page reads in the parameters and reloads the same contents
as the first page
- user can preview page and then print
I've reimplemented it using only jQuery, to make it as simple and
reusable as possible, and works like this:
- printable elements of the page either have a class or are enclosed
in a div with the class "printable"
- user clicks on Print icon, triggering a Javascript function which:
- loads a new page with print-friendly template, but with no content of its own
- on the new page, upon loading, Javascript runs to extract the
content with class "printable" from the parent window
- this content is then inserted into new page
- user can preview page and then print
The basic code is:
(add this to print page)
<script type='text/javascript'>
function printClick() {
window.open('print_template.html');
}
function getPrintContent (printSelector) {
// .clone() is required otherwise the content seems to be moved from
opening page to new page
var selections = $(printSelector).clone();
return selections;
}
$(function() {
// modify this to whatever we need to select the "Print" link.
$("li.print a").click(printClick);
});
</script>
(and on print page -- extract content from opener)
<script type='text/javascript'>
$(function() {
$('#main-content-wrapper').html( window.opener.getPrintContent('.printemail') );
});
</script>
I am inclined to replace the use of "printable" class and just enclose
all the print elements in one div and just get the contents from that
div. This is mainly due to having all our content managed in a CMS,
and if the producer does not include the "printable" class, then the
element won't get included on the print page.
'Print' and 'Email' icons.
The implementation in the old system works like this:
- user clicks on Print icon, triggering a javascript request
- request includes the portlet Id and content Id as a parameter,
opening a new page
- the new page reads in the parameters and reloads the same contents
as the first page
- user can preview page and then print
I've reimplemented it using only jQuery, to make it as simple and
reusable as possible, and works like this:
- printable elements of the page either have a class or are enclosed
in a div with the class "printable"
- user clicks on Print icon, triggering a Javascript function which:
- loads a new page with print-friendly template, but with no content of its own
- on the new page, upon loading, Javascript runs to extract the
content with class "printable" from the parent window
- this content is then inserted into new page
- user can preview page and then print
The basic code is:
(add this to print page)
<script type='text/javascript'>
function printClick() {
window.open('print_template.html');
}
function getPrintContent (printSelector) {
// .clone() is required otherwise the content seems to be moved from
opening page to new page
var selections = $(printSelector).clone();
return selections;
}
$(function() {
// modify this to whatever we need to select the "Print" link.
$("li.print a").click(printClick);
});
</script>
(and on print page -- extract content from opener)
<script type='text/javascript'>
$(function() {
$('#main-content-wrapper').html( window.opener.getPrintContent('.printemail') );
});
</script>
I am inclined to replace the use of "printable" class and just enclose
all the print elements in one div and just get the contents from that
div. This is mainly due to having all our content managed in a CMS,
and if the producer does not include the "printable" class, then the
element won't get included on the print page.
Friday, 9 November 2012
Could you please introduce yourself with more bullshit per syllable?
Anyone who starts off their comment in this manner: "As a UK based
international entrepreneur trying to bring change and transformation
with new internet architectures, technology and business models for
digital eco-systems..." is a total wanker. #rulesoftheinternet
And when you talk about looking for your "Bit Torrent login details" -
you are also a moron.
http://techcrunch.com/2012/11/07/reserving-judgements-is-a-matter-of-infinite-hope
international entrepreneur trying to bring change and transformation
with new internet architectures, technology and business models for
digital eco-systems..." is a total wanker. #rulesoftheinternet
And when you talk about looking for your "Bit Torrent login details" -
you are also a moron.
http://techcrunch.com/2012/11/07/reserving-judgements-is-a-matter-of-infinite-hope
Subscribe to:
Posts (Atom)