Zen Coding interval on producing N elements - emmet

here's a quick question on Zen Coding. If:
div.foo-$*3
produces this:
<div class="foo-1"></div>
<div class="foo-2"></div>
<div class="foo-3"></div>
What if I wanted to generate, for example, .foo-27 until .foo-245? Is there a way to set an interval in generating elements in such a manner? Is it possible for the current version of Zen Coding? I know manually deleting unnecessary tags is a way, but Zen Coding is supposed to quicken stuff up, right?
Thanks!

Currently, it’s not possible. Since it’s very specific use case, you may fill-up issue at https://github.com/sergeche/zen-coding/issues
If it get enough votes, I may think about upgrading syntax for this feature.

Related

Vue 3 Better performance of lot of DOM elements

I have a big fat sort of table with lots of elements that make it really buggy.
For context 1 row per user, each user has X projects and each project has 3 month of day display (sort of gantt)
So I built something cool it's working great, but if I scale to more users it begin to be real buggy.
I'm implementing filter to display less users but at some point it need to handle the limit that I have now without being buggy.
What I found is when I'm updating a day it re-render the whole Gantt which is really stupid.
here is a minimal reproduction link: https://stackblitz.com/edit/vitejs-vite-g6azah?file=src%2FApp.vue&terminal=dev
As you can see when I'm updating an input with the v-model:
value.value
I have the attribute with the function
:test="testRerender()"
That trigger for the whole Gantt and I believe it is the issue here.
I saw v-memo that look like what I need but I can't figure out with the doc how can I use it to match my needs (and there is almost no good article on it)
Thanks for your help you would save my life!
I tried to filled proper :key attribute, code optimization, v-memo etc...

How to style parts of i18n messages when using thymeleaf

I'm not sure this is the right place to ask this. I would like to know how best to style parts of messages from l10n properties files. For example, my client want this message and formatting in a help window:
This is a self-assessment and comparison application.
Simplest solution would be to include the HTML tags in the messages.properties entry for this label. The problem with that is that the 40 translators that will process the messages.properties are bound to make mistakes like deleting the <, translating the attributes or styles of the HTML markup etc. Also it makes maintaining the markup and styling difficult for the devs.
Any better way to do this?
The solution I've seen typically done just uses th:utext with HTML tags in the .properties files. I would opine it does create a maintenance hassle as you mention and should be kept to a minimum.
One workaround is to create separate strings in some cases, like:
<span th:text=#{thisIsA}>This is a </span><strong><span th:text="#{selfAssessment}">self-assessment</span></strong>
However, this is error-prone since certain languages may change the order of the words. So that's not a great option.
If the HTML tags specifically are an issue, another way albeit somewhat ugly could be:
thisIsASelfAssessment=This is a {0}self-assessment{1}.
Or even
thisIsA=This is a {0}.
selfAssessment=self-assessment
But that might be confusing for the next developer reading it and may introduce the same issue you have with the 40 translators looking at it since you have curly braces. It also all becomes very tedious and generates more lines.
So in the end, you're likely best going with the simplest solution of utext.
Project-wise, you could have the initial translation done without the markup and add the markup in after they are done with a first pass at translating it. The issue may arise in the future when you need to change strings, but doing this would minimize some headache. It could make sense to keep these strings in a separate block in the .properties file so you can target them later.
Good question as I've had this issue myself.

SQL Reporting Services HTML Style Tags

I'm using SQL Server Reporting Services 2008.
Per Microsoft, the following are the only tags that are supported.
Hyperlinks: <A href>
Fonts: <FONT>
Header, style and block elements: <H{n}>, <DIV>, <SPAN>,<P>, <DIV>, <LI>, <HN>
Text format: <B>, <I>, <U>, <S>
List handling: <OL>, <UL>, <LI>
My problem is that when rendering reports, style attributes are ignored. Most importantly for my problem, background color style is ignored. (I'd love support for other style tags, but this is really the big for me). I opened a support case with Microsoft, and they confirmed that this doesn't function in SQL Server 2012 either.
I've been reading about Custom Report Items - and it seems like SOMEONE must have handled this problem already, but I have now spent more time than I care to admit looking for solutions to this problem. Are there commercially available solutions to this problem? I can re-write reports using an additional reporting technology (Telerik more than likely), but I hate to spend the time and energy to do that when I've got a 98% workable solution already built using SSRS.
Just so everyone knows exactly what I'm talking about, when entering data into my database, I'm entering this data:
(I'm a new member, so I can't embed images - so I had to include as links:)
The Data I'm Entering : http://i.stack.imgur.com/xB5R4.jpg
The way SSRS displays image http://i.stack.imgur.com/UKM50.jpg
Finally, this is the way the information is being stored in the database:
<div><font style="BACKGROUND-COLOR:#FFFF00">highlighted yellow</font></div>
<div> </div>
<div><font color="#5C83B4">Blue Text, no highlight</font></div>
<div><font color="#5C83B4"> </font></div>
Does anyone have any suggestions? I can't be the first person to whom this has been a big deal for SSRS, but it seems like most people have been able to make do without this. Unfortunately, we're moving from automation of MS-Word to SSRS, so losing that important piece of functionality would be seen like a giant step back to our users.
Your question borders on asking for recommended libraries and opinions. Nonetheless, let me summarize the options and the way I see them:
Don't chop your text into divs, but use other SSRS toolbox items such as tablix cells and textboxes, and give those a background color.
Create your own component. Certainly possible, but quite a pain to get it working IMHO.
Choose a third party component. Stack Overflow isn't very good at (nor meant for) recommendations, but a quick search would render at least one result.
Switch to another reporting tool.
Drop the requirement. (Okay, you stated that's not possible for you, but others landing here may want to consider that option.)
Don't skip the final two options too quickly ;-)

RoR: how can I seperate a page on my website into two large columns?

I want to make a vertical line going through the middle of the site and then have content on either side. How can I use CSS or ruby? to do this? I am not sure which one I would need and where I would put it. Also, what is the best resource for learning the syntax of the ruby on rails views/CSS stuff. It seems that rubyonrails.org doesn't have much documentation on that (they mostly explain the models and controllers)
I would suggest you start with something like: https://github.com/softmachine/rails-bootstrap
They provide a link to http://twitter.github.com/bootstrap/ which has plenty of documentation.
The next step, would be to ask a more specific question related to the exact problem you're having.
From your description it sounds like you need css, and depending on the nature of of the information you want to display, you might need to use ruby/rails to make it happen. Most likely, you could just use css.
see: http://jsfiddle.net/aTUq8/

Should I use proper punctuation for single sentence alert/notification popups?

Is it necessary to use a period for single sentence notification boxes? Even though its considered proper grammar to do so, it just looks ugly and feels too formal.
Here are two screenies for comparison (first includes period, second doesn't).
alt text http://wordofjohn.com/files/stack_alert_1.png
alt text http://wordofjohn.com/files/stack_alert_2.png
Can't go wrong with correct grammar
Good grammar shows to your customers that you took time to make a good software even where others might not took time.
This way they can expect the best out of you and your company.
If you are using a full sentence to tell the user what to do, then I think proper grammar is important, although I always stay away from exclamation points, I find them annoying.
It is more preference that anything, but I like to maintain the best grammar possible in any situation.
In both instances you capitalized the first word in the sentence so I would say go with proper grammar
but it really is a preference
I'd vote No.
These alerts are like signposts or roadsigns, they need to present a brief but important message as succinctly as possible.
My reasoning extended - I think it's subjective, and so I doubt anyone's going to have a bad user experience because of the presense or absence of a full stop (period). A question mark might be confusing if it was left out, but a full stop is kind of implicit.
If you use periods at the end of your sentences, then users will know that the string hasn't been truncated (well OK, they won't know that it hasn't been truncated, but it's a good indicator. Plus, as others have said, it shows you went to the trouble to get it right.
I can't remember - what do MS/Apple do?
Let me explain my preference with an analogy.
I used to work at a bookstore where they sold Bibles. Some of them were Cambridge calfskin leather bound deluxe editions that came in special boxes for over US$100.00 each. Some of them were mass market paperback throw-away versions for US$1.99 each. The cheap ones often had glaring grammatical and spelling errors. I don't think this was a coincidence.
Regardless of where my software is going to be used or what it is for, I try to do my best to make sure it gets put (metaphorically) on the high-quality, expensive rack. Every time. Even at the risk of sounding "too formal".
If you are using the string as a normal resource, you (or someone else in your project) could use the text in another context, which would mean you need to keep track of which resources contain a period or not.