Vacskamati's daily code snippet

How to allow trailing slash in urls in Symfony (1.4)

2010-05-07T14:41:00.000-07:00

Symfony's routing system is made so it doesn't allow trailing slashes. It's really a problem, because it can't be solved through just some rewrite rule in .htaccess, because the request path info is not coming from .htaccess (but from the $_SYSTEM array).

Of course there is an easy solution. Symfony's factory architecture makes it easy to extend or modify built-in functionality. All you have to do is to change the routing class in factories.yml and prepare that class:

/apps/frontend/config/factories.yml:

all:
  routing:
    # class: sfPatternRouting
    class: myPatternRouting

Create the class:
apps/frontend/lib/myPatternRouting.class.php

<?php
class myPatternRouting extends sfPatternRouting
{
  protected function normalizeUrl($url)
  {
    $url = parent::normalizeUrl($url);

    // remove trailing slash
    $url = preg_replace('/\/$/', '', $url);

    return $url;
  }
}

Okey, this is it.

But maybe it's a better way to catch the flow in an earlier point. Because this way, though routing will parse urls with trailing slashes fine, but calls to $request->getPathInfo() will still give the urls with the trailing slashes. It can has some unwanted side effects. It's better if the whole framework sees the request url as if it had no trailing slash.

What to do for that? Change the request class instead of the routing.

/apps/frontend/config/factories.yml:

all:
  routing:
    class: sfPatternRouting

  request:
    class: myWebRequest

apps/frontend/lib/myWebRequest.class.php

<?php
class myWebRequest extends sfWebRequest
{
  public function getPathInfo()
  {
    $pathInfo = parent::getPathInfo();

    // cut off trailing slash
    $pathInfo = preg_replace('/\/$/', '', $pathInfo);

    return $pathInfo;
  }
}

Infinite scrolling

2010-04-28T04:51:00.000-07:00

I know this is the new magic, but c'mon.

From 0:30, i'm constantly holding the END key down.

Kényszeres poénkodás szakmai bevezető anyagokban

2008-12-07T04:46:00.000-08:00

Ennek a posztnak talán a vacskamati.blog.hu-n volna a helye, de mivel a weblabor egy újabb cikke kapcsán írom, mégis ide kerül.

Bár örökzöld a téma, mostanában mintha egyre több hangsúlyt kapna a modorosságok különböző előfordulásainak online tárgyalása. Csak két referencia: modoros.blog.hu, és az épp legutóbbi posztjukban linkelt matula-cikk: http://matula.hu/index.php?section=article&rel=35&id=418.

Hát ehhez a témához tenném hozzá a magam szemelvényét, egy meglehetősen idegesítő állatfajt: a szakmai cikkekben való kényszeres jópofiskodást. Emlékszem, régen, középiskolában írtam még egy hosszú helpet a Dos Navigator nevű shellhez. Az egész egy jó hosszú írásbeli showműsor volt. Szerencsére ma már nincs meg, így ha akarnám se tudnám pontosabban felidézni. És most sem tudom önmagamat teljesen kivonni ez alól, visszaolvasva egy-két cikkemet, néhány szófordulatot igencsak kivágnék a fenébe.

Érdekes azért ennek a nyelvi/lélektani okrendszere. Az ember egy szakmai anyagban, posztban azzal szembesül, hogy nem egyenletes a téma mélysége, számos dolgon át kell ugrania, és egyéb szövegműveleteket kell végeznie, hogy a kellő pontra tudjon koncentrálni, s erről nem árt tájékoztatni is az olvasót. Ilyenkor az előadó önreflexiót gyakorol. Más oldalról meg nyilvánvalóan segíti is a befogadást az informális hangnem.

Külföldi példákon is látni ezt, és ahogy nézem, ez egy ízléses fokig valóban hasznos jelenség. Kifejezetten a szakmai anyagokról beszélek, blogposztokról, tutorialokról, bevezetőkről, melyekben a poszt írója beleképzeli magát az olvasó helyébe, s mintegy felfedező túrát kínál neki. Szóbeli előadásokban, webcastokban ez talán kissé kevésbé szokott megjelenni, talán mert a szóbeliség már eleve hozzáadja a kellő mértékű informalitást. És persze a jó konferencia-előadók mindenre képesek.

Sajnos a magyar helyzet más, legalábbis ami a webfejlesztői szakmai közösséget illeti. Nálunk, úgy látszik, egy normális Drupal-előadást nem lehet összedobni anélkül, hogy ne menne el a fele gyerekes, ripacs jópofizással. Helyben biztos jó a hangulat, de magának az előadásnak az értékéhez nem hogy nem tesz hozzá, hanem hogynemondjam lenullázza.

Ugyanez mondható a weblabor legtöbb cikkéről, modorosság a köbön. Épp a legutóbbi cikkük hozzászólásaival van tele az RSS-em, emiatt is nem állhattam meg kiírnom magamból ezt a panaszt.

Olvashatatlan szar az egész. Kezdjük ott, hogy az illető rossz címet adott, amit aztán maga is leír, talán jobb lett volna valami olyasmi, hogy "Összeszedtem minden javascript tudásomat", vagy "De érdekes ez a javascript, gyertek, fedezzük fel együtt". Össze-vissza csapong, amit szintén leír. Érthetetlenül ad elő, túlbonyolított példákkal, amit aztán tanáruras vicceskedéssel kompenzál: „Mielőtt egered elkalandozna a jobb felső sarokba”. Bah, és ez egy úgymond szakmai fórum. Helyesírás szar. Ugyanakkor persze ott vannak az elmaradhatatlan :-), az idióta vigyorgást mutató szmájlik :-), alább a hozzászólásokban is :-), ahol kivesézik az egész hiányosságait :-), hehe, hiányosságait :-), minden mondat után :-). "Fú, de logikusak vagyunk!"

"Kemény, nem? Ezen a példán egy napig rágódtam, hogy mi is lenne az öröklődés absztrakciójához illő tudományos akármi. Jó, hát nem nagyon sikerült megtalálni a megfelelő alanyt, de legalább kis kutyusok aranyos képe lebeg előttünk!"

Az, kemény... Látszik, hogy a szerző ilyen ünnepként, felfokozott, beleélt műsorként képzeli el a műve befogadását. Mint a kis kamasz felelésnél, aki kiherélt idétlenkedéssel üti el a zavarát, hogy ő most reflektorfényben van.

"Lehet kicsit tömény, de én értem, éljen :-)"

Az ilyen mondatok a középsulis számtechtanáromra emlékeztetnek, pf, hagyjuk is. Maradjunk annyiban, hogy nem mindenki tud magyarázni. De aki erre büszke... És mondom, csak a szakmai hiányosságok és az összevisszaság kompenzálásáról van szó.

„Nos, ez lesz a legrövidebb része a cikknek, ugyanis minimum külön cikket érdemelne, és jómagam sem vagyok eléggé olvasott ahhoz, hogy egy ilyen témába belevágjak. Jó, leírhatnánk ide egy két egykét (hát ez nagyon vicces!), de nem tesszük. Akit nagyon érdekel a téma, guglizzon reá!”

Cikk.

One-time execution of IE CSS expressions

2008-10-17T17:08:00.000-07:00

You know guys, CSS expressions in IE (6 and 7) is a nice and powerful tool, which offers an excellent way to overcome compatibility issues. Dozens of missing W3C features can be emulated simply by an expression. It's so elegant and comfortable to solve the issues of lack of standards with them. You can make behaviours for :first-child, max-height, :hover, cellspacing/cellpadding, different kinds of selector operators etc. Ok, we know that, but hey, they say at Yahoo that CSS expressions are nasty, they want me to avoid them and instead use javascript. Yahoo says that expressions are evaluated so frequently that that is untenable. Well, the fact is, he's right.

But I love expressions.

Last time, I wanted to use the inherit value, which is not supported in IE6/7. Pretty tiny problem, the solution is:

.elem {
  background-position: expression(parentNode.style.backgroundPosition);
}

The place where class .elem elements appeared was deeply in a tag soup of a complex menu, where some layered CSS sprites inherited the containers background-position, so it was a hit on the responsiveness of the menu hover effect, of course. It got executed on every mouse movement for every menu item in the structure and, overall, thousands times in some seconds.

What to do now. Yahoo says: „One way to reduce the number of times your CSS expression is evaluated is to use one-time expressions, where the first time the expression is evaluated it sets the style property to an explicit value, which replaces the CSS expression.” This sounds exciting, but don't know how to do that. To put it short, someone asks about this in the comments in the above linked Yahoo page, and Steve Souders answers with a link to a testpage. He calls an external function in the expression which function then sets the element's style property:

<script>
function setOnetimeBgcolor(elem) {
  elem.style.backgroundColor = <some calculation>;
}
</script>
<style>
P {
  background-color: expression(setOnetimeBgcolor(this));
}
</style>

This can be rewritten in one expression:

/* It works. */
P {
  background-color: expression(
    new Function('elem', 'elem.style.backgroundColor = <some calculation>;')(this)
  );
}

Here we are, this works. The expression will be evaluated only one time. Now comes the interesting part. When I copied this solution in my working context to emulate inherit on the background-position property, it didn't work:

/* WON'T WORK */
.elem {
  background-position: expression(
    new Function('e', 'e.style.backgroundPosition = e.parentNode.style.backgroundPosition;')(this)
  );
}

The inherit behaviour itself was live, but it was as terribly sluggish as before. I made a test with a counter and it turned out that the expression actually didn't overwrite itself and was getting evaluated continuously. The method failed. But why does it work on Steve Souders' example page?

After some debugging I've found that, unlike background-color, a background-position expression can't overwrite itself with a static value. It seems that CSS properties differ in the manner of which one of them can or cannot overwrite themselves. For example, background-color can. Display can. Background-position can't. Float and height also can't, but clear can...!

Very interesting, but it's the very truth.

So now I took an 'assistance' property which is self-overwritable, let this be clear. Watch it, it's only used as a dummy assistance property. Then set the value of background-position in it, which is not self-overwritable, and lastly overwrote the assistance property. This trick even allows us to avoid function creation:

.elem {
  background-position: inherit;
  *clear: expression(
    style.backgroundPosition = parentNode.style.backgroundPosition,
    style.clear = "none"
    /* debug: */
    , window.expc = window.expc || 0,
    window.defaultStatus = expc++
  );
}

This is it. The menu was absolutely responsive. The expression runs only one time. You can experiment, the debug lines show the number of executions in the browser's status bar. I think it is the recommended way of CSS expression usage with any CSS property, when working around compatibility issues.

It's important to note that you cannot use the underscore hack (_clear) in case of expressions intented only for IE6, because it will run on IE7 too. In such situations you have to separate it by other ways.

UPDATE

Yet, it's still not the end, there's another catch. If you remove the debug lines from the above example, IE gently will hang up. Put a simple value, e.g. a 0 in place of that, and it will work:

/* Final example, the ultimate way of writing one-time CSS expressions */

.elem {
  
  /* we want to implement the unsupported 'inherit' value */
  background-position: inherit;

  /* 'clear' is a dummy property */
  *clear: expression(

    /* this is the actual assignment */
    style.backgroundPosition = parentNode.style.backgroundPosition,

    /* overwriting dummy property, 0 needed to avoid crash */
    style.clear = "none", 0
  );
}

The IE6 :hover workaround

2008-10-17T05:37:00.000-07:00

Kids, I've found the best and ultimate workaround solution for the hover problem of IE6. Unfortunately my discovery is a little overdue, because this hackers-heaven product, IE6 gets outdated, so consider this announcement an archaeologist's curiosity. Let's get to the point.

:hover pseudo selectors only work on links in IE6. You have to make it work on non-link elements, too. What you do? Your first thought is IE's magic equipment, Mr. Expression. You'll be trying, but won't succeed. But project deadline is coming, so you go to your template and hardcode onmouseovers and onmouseouts in your tag soup. Oh no, you say. Oh no. You cry. Later on you periodically review your code, and your eyes always stop on these onmouseovers and onmouseouts, and you always cry.

Ok, seriously, expression works. As it is shown here. He takes a random css property and gives the javascript onmouseover assignment as a value to it. There's two problems with it. First, it makes the behaviour totally sluggish because the assigment is interpreted i-don't-know-how-many times in every second. And it continuously creates new functions, and it's beeing garbage collected etc. Second, no need to play with the classnames.

Simply put:

a.dropdown-item {
  _m: expression(onmouseover = onmouseover || new Function("$(this).down().style.display = 'block'") : '');
  _n: expression(onmouseout = onmouseout || new Function("$(this).down().style.display = 'none'") : '');
}

You see? We check if the assigment has already done and hence it will be blazing fast. That's the big idea.

Essentially that's all that I wanted to share with you, my precious fellows. Two more notes: String assigment to the onmouseover and onmouseout properties won't work. You have to create functions explicitely. Lastly, no need for "this." prefix, however this is the nice way, but remember, in hacks there's no nice way.

UPDATE

Fine, an even more beautiful snippet is here.

Weblaboros hülyeségek

2008-09-07T05:07:00.000-07:00

Túl sok volt a szabadidőm, úgyhogy most írok egy posztot a weblabor.hu hülyeségeiről. A Weblabor az egy webfejlesztői fórum.

--
UPDATE -- 2008.09.30. 1:14:58

A Weblabor egy-két héttel ezelőtt megújult, így az alábbi listából a 2-es és az 5-ös pont érvényét vesztette. Továbbá mivel hivatkozást kaptam erre a posztra, meg kell jegyeznem, hogy ez itt csak egy alulszociált elme fröcsögése, természetesen azért kapja mindezt a Weblabor, mert szeretem.
--

1. „Hozzászólás témája”

(Topik itt: http://weblabor.hu/forumok/temak/19242)

Színtiszta hülyeség. Eleve ugye egy topikban vagyunk, vagyis a hozzászólásom témája nyilvánvalóan a topikcím. Ezen kívül meg nyilvánvalóan reagálok valakinek a hozzászólására, vagy a posztra. Az ez (reagálás) alatti absztrakciós szinten már csak a mondanivaló van, a kettő közé betuszakolni egy címet még, egy folyamatos diskurzusban, nettó hülyeség. Erőltetés. De elterjedt az a belterjes tévhit, hogy ez hasznos. Hát, hasznos lenne még az is, biztos, ha esetleg minden hozzászóláshoz kötelezően képillusztrációt is kéne mellékelni. Ésszerűtlen trade-off.

2. RSS

(Topik itt: http://weblabor.hu/forumok/temak/19242)

Hogyaszongya Drupal, ezért nem képesek megvalósítani, hogy egy fórumhozzászólásokról szóló RSS-ben a From mező (author stb., kinek milyen olvasója van) a hozzászóló nickjét tartalmazza. Ez kb. 3 perc munka, aki már dolgozott valaha RSS-sel. Ja de hogy Drupal, meg hogy inkább frissítés.

3. Nagybetűs névmások és névutók

(Topik itt: http://weblabor.hu/forumok/temak/19382)

Belterjes helyesírási konvenció a tiszteletadásra. Jószándékú hülyeség. Azért hülyeség, mert csak a szakmaiság rovására megy, ha az egyébként favorizált (bár gyengén követett) helyesírás normájától így eltérnek. Másrészt meg van benne egy kis hiperkorrekció, meg egy kis kompenzáció a flame-kultúrával szemben. Akárki akármit mond.

4. hacker/cracker

(Topik itt: http://weblabor.hu/forumok/temak/22315)

Ezek képesek voltak egy topikcímben átszerkeszteni a hacker szót crackerre, mert hogyaszongya a nagykönyv szerint a cracker a csúnya fiú, a hacker meg a jó fiú. De a hacker is lehet csúnya fiú, de mivel a cracker biztos specifikusabb, hát tekintsük ezt itten – mégiscsak egy „szakmai” fórumban vagyunk – hibának, amit ki kell javítani. És a csóka leírja, hogy ja, hát ha mindezt te is tudod, akkor végülis nincs is hiba, de én feltételeztem, hogy te nem tudod, ezért jól beleugattam, nehogy véletlenül a közvélemény félreértsen engem, jó fiút. Istenem, butaság, belterjesség a neved.

5. Ó, hirdetés

(Topik itt: http://weblabor.hu/blog/20080502/munka-rovat-moderacio)

Hát ez majdnem lemaradt. A kedves szerkesztők tudatában valamiért megszilárdult egy olyan képzet, nyelvi asszociáció, mely szerint a konkrét szó azt jelenti, hogy nem projektmunka. Ennek tudatában vígan törölgetik azokat a hirdetéseket, melyekről úgy gondolják, hogy az nem konkrét. Az, hogy egyesek ezt nem értik? Hát, biztos nem elég lojálisak a nyájasan belterjes szerkesztői inkompetenciához.

Naon filter updated

2008-04-03T20:23:00.000-07:00

Az eredeti bejegyzés itt.

- Kicsit jobb és egyszerűbb metódus.
- Csak *.hu alatt keres.
- Kicseréli az ajax-al típusú borzalmakat is.
- A document.title-t is szűri.
- update 2008.04.11.: index.hu Anyádat rovat átnevezve "Hülye vagyok"-ra.

Szóval hajrá.

nagyon.user.js

ExtJS DatePicker patch for Firefox 3

2008-04-02T18:57:00.000-07:00

ExtJS's DatePicker is broken in FF3 (for the time being up to RC1).

Here is a patch. This is for ExtJS 2.0.2.

ext-all-debug.js: after line 17999 insert the highlighted statement below:

el.className = "x-date-picker";
el.style.width = '10px';
el.innerHTML = m.join("");

ext-all.js is minified, so you have to search for "x-date-picker", then you'll see that the statement looks a bit different. Thus, we modify the patch also:

B.className="x-date-picker";B.style.width = '10px';B.innerHTML=C.join("");...

Naon filter

2007-12-25T18:15:00.000-08:00

Ha téged is idegesít a lazázó naonozás, íme egy userscript, ami szűri, azaz nagyonná változtatja a naonokat.

nagyon.user.js

Peek-a-boo in IE 7

2007-11-20T19:27:00.000-08:00

They say at positioneverything.net that the so-called peek-a-boo bug has been suppressed in IE7. Actually, it's not.

weblabor tuning userscript

2007-10-06T02:07:00.000-07:00

A script két részből áll:

- Hozzászólásszerkesztő autosubject: automatikusan kitölti a "téma" mezőt a komment szövegtörzsének elejével. Hárompont ott figyel a végén, szavakat nem töri, csak az első mondatig keres, köszönéseket kihagyja. Ha manuálisan megváltoztatjuk a témát, az automatika kikapcsol. Be- kikapcs állapota sárga háttérrel jelezve.

- Követő tuning: Gmail-szerű hozzászólás-előnézet, mouseover-re a teljes hozzászólás látszik.

Böngészők: FF, Opera

Letöltés:

Weblabor tuning -- autosubject.user.js

Making custom tabs in CSS

2007-07-26T16:46:00.000-07:00

Tab customization is a common task in the CSS world. Obviously this is done by using background images. The point of the problem is that you have to make it flexible, so that it follows the width of the tab caption. It's a bit related to the skinning issues of UI systems, where you have to split the template to many small parts (borders, corners etc.).

Well, in CSS, for the classic and average tab customization, image splitting is simply not needed. Though generally CSS coders don't recognize this. They split the tab image in two, or in the worst case, three parts: a left side, a middle part, and a right side. But, again, this is unnecessary.

Just look at this simple markup:

A tab link is an <a> element, and the caption is wrapped in a <span>. Both have the same custom background image, which is the tab template.
It's wide enough to make the long captions fit in. So in one element the tab image is left aligned, while in the other is right aligned, so we see both sides of the template. But how is that one layer doesn't overlap the other side?

This is where if a CSS designer isn't smart enough, he or she cuts off one (e.g. the left) side of the image to make it overlayed above the other layer (which has the right aligned background). Because he/she doesn't realise that cutting also can be performed with CSS. See that blue rectangle around the Search tab? That is the span element, which has the left aligned background. It has a 12px right-margin to leave space for the underlying <a> tag showing the right side.

The IE border-spacing workaround

2007-03-10T05:09:00.000-08:00

Everyone knows these two HTML table tag attributes: cellpadding and cellspacing. And everyone hates the annoying necessity of these attributes in the CSS era. Well, developers, who has looked after what's up now about this issue, have learned that fortunately the cellpadding attribute is safely substitutable with the padding value of the table cells.

But what about cellspacing?

Cellspacing can also be omitted if you work with the border-collapsing model, because IE supports this model in CSS. (Or maybe not; we'll come back to this later.) Anyway, just put border-collapse: collapse in your table's style, and all the space between your table cells will be gone, and the adjacent borders will collapse to one simple border.

(For those of you who didn't fully get the picture, here is a nice illustration of the two border models.)

Problems will arise when you want to use the separated borders model. In this mode the CSS engine (browser) is expected to apply the td border styles separatedly to every single table cell, just as these were simple divs. We can think of this as the normal behaviour, and the collapsing model as a special case, if only because that the former is the initial (default) value in the CSS specs. When you're in the 'separate' model, you can control the space between your table cells with the border-spacing value of the table. You can set the horizontal and the vertical spacing.

But the problem is that IE doesn't support the CSS border-spacing attribute. Instead it puts a fixed 2px space between the cells. This is the point, where normally a developer gives up, becomes a bit melancholy, and puts back the cellspacing attribute into the HTML code. The conclusion: cellspacing can't be controlled by CSS (cross-browser).

Some good news

However, there is some consolation: generally you don't need that. Usually we only need to eliminate that bad looking space between the cells, and this can be achieved by CSS, even in IE. And the good news is that not only in the 'collapse' model but even in the separated!

Say, we want a table, in which all table rows have a red 1px bottom border, and a pink 1px top border (we want it to look a bit like buttons). 'Collapse' model is not an option now. This is a situation, where we have to use the 'separate' model with 0-width border-spacing between the cells.

For this the standard CSS code is as follows:

table {
 border-collapse: separate;
}

td {
 border-top: 1px solid red;
 border-bottom: 1px solid pink;
}

It works in the standard compliant browsers, but what about IE?

That's a Feature, Not a Bug

Thankfully, IE is so buggy, that one bug helps to fix an other. So, what to do if I want to achieve a zero-spacing separating model? Exploit the bugs in the collapsing model! IE's border collapsing works fine, but magically gets switched off, if you give a 'position: relative' style to the table cells. If you do this, the browser jumps back to the separated model, width 0 cellspacing! Thx, Mr. Bug.

table {
 border-collapse: separate;
 border-spacing: 0;
 *border-collapse: collapse; /* hack is needed for IE7 also */
}

td {
 border-top: 1px solid red;
 border-bottom: 1px solid pink;
 *position: relative;
}

This way, you don't need any of those ugly HTML tag attributes, while working in either a collapsed, or a 0-cellspacing separated borders model. Have fun!

UPDATE

knakts noted in his comment that this workaround provides solution only to those cases in which the border-spacing value is zero. And I felt sympathy for him/her. Thus, as a matter of urgency, I researched another workaround, which brings us closer to the heaven.

Here it is:

table {
 border-collapse: separate;
 border-spacing: 5px;
 *border-collapse: expression('separate', cellSpacing = '5px');
}

Still not perfect, because you can't differentiate vertical and horizontal spacing, but, as I said, one small step to the happiness.

knakts, don't be melancholic!

UPDATE 2 on 2009.05.05.

Check out this. An article about how to make it really behave like a one-time-running configuration, instead of the usual CSS expression behaviour with the well-known huge performance hit.