Author: jdimanos(a)jboss.com
Date: 2009-04-05 01:35:29 -0400 (Sun, 05 Apr 2009)
New Revision: 7976
Modified:
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po
Log:
update
Modified: enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po
===================================================================
---
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po 2009-04-04
11:01:41 UTC (rev 7975)
+++
enterprise-docs/tags/JBoss_EAP_4_3/Cache_Pojo_Cache_Guide/de-DE/Architecture.po 2009-04-05
05:35:29 UTC (rev 7976)
@@ -8,7 +8,7 @@
"Project-Id-Version: Architecture\n"
"Report-Msgid-Bugs-To:
http://bugs.kde.org\n"
"POT-Creation-Date: 2008-09-21 04:57+0000\n"
-"PO-Revision-Date: 2009-04-04 21:52+1100\n"
+"PO-Revision-Date: 2009-04-05 15:34+1000\n"
"Last-Translator: \n"
"Language-Team: <en(a)li.org>\n"
"MIME-Version: 1.0\n"
@@ -419,6 +419,8 @@
"relationship. PojoCache, in contrast, can manage object relationship "
"transparently for users."
msgstr ""
+"Wie schon erwähnt unterstützt das traditionelle Cache-System kein Management der
Objektbeziehung während der Serialisierung (ob zum persistenten Datenspeicher oder zu
anderen speicherinternen Nodes.) "
+"Beispiele für eine Objektbeziehung sind etwa ein Adressobjekt, das von Mitgliedern
desselben Haushalts geteilt wird und eine Eltern-Kind-Beziehung
(\"child-parent\"). All diese Beziehungen gehen bei Replikation oder
Persistierung der Objekte verloren. Daher ist explizites Mapping außerhalb des
Cache-Systems notwendig, um die Objektbeziehung auszudrücken. Im Gegensatz dazu kann
PojoCache Objektbeziehung für Nutzer transparent managen."
#. Tag: para
#: Architecture.xml:115
@@ -642,7 +644,6 @@
#. Tag: para
#: Architecture.xml:141
#, no-c-format
-#, fuzzy
msgid ""
"PojoCache preserves the POJO object inheritance hierarchy automatically. For
"
"example, if a <literal>Student</literal> extends
<literal>Person</literal> "
@@ -651,12 +652,8 @@
"cache, all the class attributes of <literal>Person</literal> can be
managed "
"as well."
msgstr ""
-"PojoCache bewahrt die POJO Objektvererbungshierarchie automatisch. For "
-"example, if a <literal>Student</literal> extends
<literal>Person</literal> "
-"with an additional field <literal>year</literal> (see POJO definition
in the "
-"Appendix section), then once <literal>Student</literal> is put into the
"
-"cache, all the class attributes of <literal>Person</literal> can be
managed "
-"as well."
+"PojoCache bewahrt die POJO Objektvererbungshierarchie automatisch. Wenn zum
Beispiel ein <literal>Student</literal> <literal>Person</literal>
"
+"durch ein zusätzliches Feld <literal>year</literal> erweitert (siehe
POJO-Definition im Anhang), dann können - nachdem <literal>Student</literal>
im Cache platziert wurde - alle Klassenattribute von <literal>Person</literal>
ebenfalls gemanagt werden."
#. Tag: para
#: Architecture.xml:144
@@ -665,6 +662,8 @@
"Following is a code snippet that illustrates how the inheritance behavior of
"
"a POJO is maintained. Again, no special configuration is needed."
msgstr ""
+"Nachfolgend sehen Sie einen Code-Schnipsel, der illustriert, wie das
Vererbungsverhalten eines "
+"POJO aufrechterhalen wird. Erneut ist keine spezielle Konfiguration nötig."
#. Tag: programlisting
#: Architecture.xml:147
@@ -706,7 +705,7 @@
#: Architecture.xml:148
#, no-c-format
msgid "Collection class proxy"
-msgstr ""
+msgstr "Proxy der Collection-Klasse"
#. Tag: para
#: Architecture.xml:149
@@ -728,6 +727,14 @@
"retrieve this proxy reference and use this reference to perform POJO "
"operations."
msgstr ""
+"Die POJO-Klassen, die von <literal>Set</literal>,
<literal>List</"
+"literal> und <literal>Map</literal> erben, werden automatisch als
\"aspektisiert\" "
+"behandelt. Das heißt, der Nutzer muss diese nicht als \"vorbereitet\" in
der xml-Konfigurationsdatei "
+"oder über Annotation deklarieren. Da es uns nicht erlaubt ist, die
Java-Systembibliothek zu instrumentieren, verwenden wir stattdessen die
Proxy-Vorgehensweise. Das heißt, wenn wir auf eine Collection-Instanz stoßen werden wir:
<itemizedlist> <listitem> "
+"<para>Eine Collection-Proxy-Instanz erstellen und diese im Cache platzieren
(anstelle der ursprünglichen Referenz). Das Mapping der Collection-Elemente erfolgt wie
erwartet rekursiv.</para> </listitem> <listitem> "
+"<para>Ist die Collection-Instanz ein Unter-Objekt, etwa in einem anderen
POJO, "
+"so ersetzen wir die ursprüngliche Referenz durch das neue Proxy, um transparente
Verwendung zu ermöglichen.</para> </listitem> </itemizedlist> Um die
Proxy-Referenz "
+"zu erhalten, können Nutzer ein anderes <literal>getObject</literal>
verwenden, um diese Proxy-Referenz abzurufen und diese Referenz zur Durchführung von
POJO-Operationen verwenden."
#. Tag: para
#: Architecture.xml:160
@@ -736,6 +743,8 @@
"Here is a code snippet that illustrates the usage of a Collection proxy "
"reference:"
msgstr ""
+"Nachfolgend sehen Sie einen Code-Schnipsel, der die Verwendung einer
Collection-Proxy-Referenz "
+"illustriert:"
#. Tag: programlisting
#: Architecture.xml:163
@@ -769,7 +778,7 @@
msgid ""
"Here is another snippet to illustrate the dynamic swapping of the Collection
"
"reference when it is embedded inside another object:"
-msgstr ""
+msgstr "Hier ist ein weiterer Schnipsel, um den dynamischen Code-Tausch der
Collection-Referenz zu illustrieren, wenn sie innerhalb eines anderen Objekts eingebettet
ist:"
#. Tag: programlisting
#: Architecture.xml:167
@@ -805,7 +814,7 @@
msgid ""
"As you can see, <literal>getLanguages</literal> simply returns the
field "
"reference that has been swapped out for the proxy reference counterpart."
-msgstr ""
+msgstr "Wie Sie sehen gibt <literal>getLanguages</literal> einfach die
Feldreferenz wieder, die für das Proxy-Referenz Gegenstück ausgetauscht wurde."
#. Tag: para
#: Architecture.xml:171
@@ -816,6 +825,9 @@
"since we will update the in-memory copy of that reference during detachment.
"
"Below is a code snippet illustrating this:"
msgstr ""
+"Wenn Sie schließlich eine Collection-Referenz aus dem Cache entfernen (z.B. mittels
"
+"<literal>removeObject</literal>), können Sie die Proxy-Referenz immer
noch verwenden, da wir die speicherinterne Kopie dieser Referenz während der Ablösung
(\"Detachment\") aktualisieren. "
+"Nachfolgend sehen Sie einen dies illustrierenden Code-Schnipsel:"
#. Tag: programlisting
#: Architecture.xml:174
@@ -849,7 +861,7 @@
#: Architecture.xml:175
#, no-c-format
msgid "Limitation"
-msgstr ""
+msgstr "Einschränkung"
#. Tag: para
#: Architecture.xml:176
@@ -858,7 +870,7 @@
"Use of Collection class in PojoCache helps you to track fine-grained changes
"
"in your collection fields automatically. However, current implementation has
"
"the follow limitation that we plan to address soon."
-msgstr ""
+msgstr "Die Verwendung der Collection-Klasse in PojoCache hilft Ihnen bei der
automatischen Verfolgung feinkörniger Änderungen in Ihren Collection-Feldern. Die aktuelle
Implementierung besitzt jedoch folgende Einschränkung, die wir bald angehen werden."
#. Tag: para
#: Architecture.xml:179
@@ -873,6 +885,14 @@
"ArrayList implementation. The Map interface maps to java.util.HashMap "
"implementation."
msgstr ""
+"Derzeit unterstützen wir nur eine eingeschränkte Implementierung von
Collection-Klassen. "
+"Das bedeutet, wir unterstützen APIs in List, Set und Map. Da die APIs keine "
+"Einschränkungen wie den NULL-Schlüssel oder Wert fordern, wird das Mapping der
"
+"Nutzer-Instanz zu unserem Proxy schwierig. ArrayList zum Beispiel würde NULL
"
+"Wert gestatten, eine andere Implementierung jedoch nicht. Das Set-Interface mappt
zur "
+"java.util.HashSet Implementierung. Das List-Interface mappt zur java.util."
+"ArrayList Implementierung. Das Map-Interface mappt zur java.util.HashMap "
+"Implementierung."
#. Tag: para
#: Architecture.xml:182
@@ -884,4 +904,9 @@
"items to a Set is slower than a List or Map, since Set does not allow "
"duplicate entries."
msgstr ""
+"Ein weiteres verwandtes Problem ist die erwartete Performance. Die aktuelle "
+"Implementierung etwa ist geordnet, was \"insert/delete\"
(einfügen/löschen) von der Collection "
+"langsam macht. Performance zwischen Set, Map und List Collections variiert
ebenfalls. Das Hinzufügen "
+"von Posten zu Set ist langsamer als bei List oder Map, da Set keine doppelten
Einträge "
+"gestattet."