<?xml version="1.0" encoding="utf-8"?><?xml-stylesheet title="XSL formatting" type="text/xsl" href="http://blog.invenzzia.org/pl/feed/rss2/xslt" ?><rss version="2.0"
  xmlns:dc="http://purl.org/dc/elements/1.1/"
  xmlns:wfw="http://wellformedweb.org/CommentAPI/"
  xmlns:content="http://purl.org/rss/1.0/modules/content/"
  xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
  <title>Invenzzia... po polsku - Tag - Open Power Forms</title>
  <link>http://blog.invenzzia.org/pl/</link>
  <atom:link href="http://blog.invenzzia.org/pl/feed/tag/Open%20Power%20Forms/rss2" rel="self" type="application/rss+xml"/>
  <description></description>
  <language>pl</language>
  <pubDate>sob, 15 sty 2011 22:56:54 +0100</pubDate>
  <copyright>Copyright &amp;copy; Invenzzia</copyright>
  <docs>http://blogs.law.harvard.edu/tech/rss</docs>
  <generator>Dotclear</generator>
  
    
  <item>
    <title>Głębsze przetwarzanie</title>
    <link>http://blog.invenzzia.org/pl/post/Glebsze-przetwarzanie</link>
    <guid isPermaLink="false">urn:md5:816c5be6adacf6b106cabd838e3353cd</guid>
    <pubDate>czw, 31 sty 2008 13:08:00 +0100</pubDate>
    <dc:creator>Zyx</dc:creator>
        <category>Open Power Template</category>
        <category>Open Power Forms</category>    
    <description>&lt;p&gt;Ostatni projekt, jaki realizowałem z użyciem Open Power Forms, ukazał kilka słabych punktów aktualnej implementacji. Było tam kilka formularzy umożliwiających masowe dodawanie rekordów jednego typu, tj. była sobie tabelka, w kolumnach pola: Imię, Nazwisko, PESEL, coś tam innego i było tak 30 wierszy. Razem można było za jednym zamachem dodać do 30 rekordów. O ile metodę &lt;em&gt;map()&lt;/em&gt; dało się jeszcze dość łatwo zmusić do przetworzenia czegoś takiego bez rozpisywania się, o tyle połączenie z szablonem zaczęło już wtedy szwankować.&lt;/p&gt;    &lt;p&gt;Kod prezentował się następująco:&lt;/p&gt;

&lt;pre name=&quot;code&quot; class=&quot;php&quot;&gt;$this -&amp;gt; map('names', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -&amp;gt; map('surnames', new opfArrayContainer(
	new opfConstraint(MAP_TYPE, TYPE_STRING),
	new opfConstraint(MAP_LEN_GT, 2)
), OPF_OPTIONAL);
$this -&amp;gt; map('pesels', new opfArrayContainer(
	new sConstraint(MAP_PESEL)
), OPF_OPTIONAL);
&lt;/pre&gt;


&lt;p&gt;Innymi słowy, do skryptu musiało przyjść np. pole &quot;names&quot; będące tablicą z 30-ma komórkami, w których były poszczególne imiona. Okazało się, że gdy w takiej strukturze zrobiło się gdzieś błąd powodujący, że nie chciało to przejść przez kontrolę poprawności, renderer formularzy wariował i w ogóle nie wiedział, który komponent ma oznaczyć jako błędny. Ostatecznie dodałem do kodu biblioteki na sztywno obsługę stałej &lt;em&gt;IGNORE_OPF_ERRORS&lt;/em&gt;, tak aby po prostu siedział wtedy cicho i wyświetlał formularz bez żadnego oznaczania na czerwono itd.&lt;/p&gt;


&lt;p&gt;Oczywiście takie rozwiązanie na dłuższą metę nie przejdzie i trzeba wymyślić jakieś usprawnienie. W dodatku dobrze, aby to usprawnienie elegancko komponowało się z resztą kodu i faktycznie było intuicyjne do pojęcia, bo nie sztuka dodać coś w 20 minut, a miesiąc później klnąć, że się nie chciało dokładniej pomyśleć. Najlepsze są rozwiązania proste i skuteczne, dlatego zacząłem się zastanawiać, czy można opisać formularz kilkoma definicjami i przekształceniami tak, aby na ich podstawie można było uzyskać dowolną konfigurację z gwarancją, że OPF ją obsłuży. Mój pomysł opiera się na tym, aby zejść nieco głębiej i zrównać w definicji formularz oraz pole formularza. Powodem jest kilka podobieństw:&lt;/p&gt;
&lt;ol&gt;
&lt;li&gt;Oba mogą mieć pewną wartość (przy czym dla formularza definiujemy ją jako zbiór wartości wszystkich pod-elementów)&lt;/li&gt;
&lt;li&gt;Oba mają pewien stan oraz mogą go zmieniać w trakcie przetwarzania.&lt;/li&gt;
&lt;li&gt;Oba są przetwarzane.&lt;/li&gt;
&lt;/ol&gt;

&lt;p&gt;Teraz wystarczy, że potraktujemy formularz jako kontrolkę, która może przechowywać inne pola. Jeżeli spróbujemy teraz wymodelować powyższy przykład, wyglądałoby to mniej więcej tak: tworzymy sobie formularz dla pojedynczej osoby: Imię, Nazwisko, PESEL i coś tam jeszcze. Następnie osadzamy go w większym formularzu i zapętlamy tak, aby mógł pojawić się do 30-tu razy. Możemy także łatwo uzyskać efekt umieszczenia w &lt;em&gt;opfArrayContainer()&lt;/em&gt; pojedynczego pola tak, jak to było dotychczas - po prostu umieszczamy w takiej pętli nie cały formularz, ale pojedynczą kontrolkę.&lt;/p&gt;


&lt;p&gt;Pozostaje jeszcze kwestia nauczenia komponentów korzystania z takiej struktury, ale nie sądzę, aby było przesadnie skomplikowane, zwłaszcza w świetle tego, co szykuje nowy Open Power Template.&lt;/p&gt;</description>
    
    
    
          <comments>http://blog.invenzzia.org/pl/post/Glebsze-przetwarzanie#comment-form</comments>
      <wfw:comment>http://blog.invenzzia.org/pl/post/Glebsze-przetwarzanie#comment-form</wfw:comment>
      <wfw:commentRss>http://blog.invenzzia.org/pl/feed/atom/comments/4</wfw:commentRss>
      </item>
    
</channel>
</rss>
