Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » Explicitly storing default values in XML resources
Explicitly storing default values in XML resources [message #638034] Tue, 09 November 2010 17:04 Go to next message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
Hi,

I have tried generating an EMF editor to edit XML instances of a given
(rather complex) XSD file today. I created a genmodel from the XSD and
then generated all the model, edit and editor code. Everything worked
out of the box. This is way cool!

My only problem is that when I create model instances with the generated
editor, default values of booleans or enums are not stored in the
resulting XML file. I did a search for this topic and found out about
the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the generated
editors doSave() method and added this option at the beginning. This
seems to be the correct point to do this (I have tried out the
OPTION_FORMATTED option as well, and it behaves as expected).
Also, when I set a property to some non-default value, save, and then
set it back to the default, it keeps being stored in the XML file.
However, unmodified default values are not stored, apparently.

Of course, I do not want to modify each enum-based property once for
every model, so: is there a way to achieve what I want? Did I do or
understand anything wrong?

Cheers,
Stefan
Re: Explicitly storing default values in XML resources [message #638185 is a reply to message #638034] Wed, 10 November 2010 10:01 Go to previous messageGo to next message
Stefan Winkler is currently offline Stefan Winkler
Messages: 277
Registered: July 2009
Location: Germany
Senior Member
Hi again,

Used the debugger I have gained a few more insights.

First, better than changing doSave() in the editor is actually adding
the option to the defaultSaveOptions of the generated ResourceImpl for
my XML file.

Second, the problem seems to be that the defaultFeatureValueLiteral of
the affected features is null, which is why
XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
question is, why does the property view show a concrete value for the
boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
unset feature with a null default and does not save it.

I guess, I could work around this issue by changing my xsd2ecore map and
set proper default values everywhere. But my question remains: Why is
the property view and the saved resource inconsistent?

Cheers,
Stefan



Am 09.11.10 18:04, schrieb Stefan Winkler:
> Hi,
>
> I have tried generating an EMF editor to edit XML instances of a given
> (rather complex) XSD file today. I created a genmodel from the XSD and
> then generated all the model, edit and editor code. Everything worked
> out of the box. This is way cool!
>
> My only problem is that when I create model instances with the generated
> editor, default values of booleans or enums are not stored in the
> resulting XML file. I did a search for this topic and found out about
> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the generated
> editors doSave() method and added this option at the beginning. This
> seems to be the correct point to do this (I have tried out the
> OPTION_FORMATTED option as well, and it behaves as expected).
> Also, when I set a property to some non-default value, save, and then
> set it back to the default, it keeps being stored in the XML file.
> However, unmodified default values are not stored, apparently.
>
> Of course, I do not want to modify each enum-based property once for
> every model, so: is there a way to achieve what I want? Did I do or
> understand anything wrong?
>
> Cheers,
> Stefan
>
>
Re: Explicitly storing default values in XML resources [message #638270 is a reply to message #638185] Wed, 10 November 2010 14:58 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26048
Registered: July 2009
Senior Member
Stefan,

Comments below.

Stefan Winkler wrote:
> Hi again,
>
> Used the debugger I have gained a few more insights.
>
> First, better than changing doSave() in the editor is actually adding
> the option to the defaultSaveOptions of the generated ResourceImpl for
> my XML file.
>
> Second, the problem seems to be that the defaultFeatureValueLiteral of
> the affected features is null, which is why
> XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
> question is, why does the property view show a concrete value for the
> boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
> unset feature with a null default and does not save it.
It's impossible for a primitive value to be null. EEnums are treated by
EMF like primitives.
>
> I guess, I could work around this issue by changing my xsd2ecore map
> and set proper default values everywhere. But my question remains: Why
> is the property view and the saved resource inconsistent?
The properties view shows the logical value. The same one returned by
calling the getter...
>
> Cheers,
> Stefan
>
>
>
> Am 09.11.10 18:04, schrieb Stefan Winkler:
>> Hi,
>>
>> I have tried generating an EMF editor to edit XML instances of a given
>> (rather complex) XSD file today. I created a genmodel from the XSD and
>> then generated all the model, edit and editor code. Everything worked
>> out of the box. This is way cool!
>>
>> My only problem is that when I create model instances with the generated
>> editor, default values of booleans or enums are not stored in the
>> resulting XML file.
I'd expect that. I wonder why you consider that a problem? The whole
point of default values in a schema is so that the actually instances
don't need to contain such a value in order for it to be the "effective
value."
>> I did a search for this topic and found out about
>> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the generated
>> editors doSave() method and added this option at the beginning. This
>> seems to be the correct point to do this (I have tried out the
>> OPTION_FORMATTED option as well, and it behaves as expected).
>> Also, when I set a property to some non-default value, save, and then
>> set it back to the default, it keeps being stored in the XML file.
>> However, unmodified default values are not stored, apparently.
As the option says, it only keeps explicit defaults, not intrinsic
defaults. (E.g., zero for the primitive numeric types).
>>
>> Of course, I do not want to modify each enum-based property once for
>> every model, so: is there a way to achieve what I want? Did I do or
>> understand anything wrong?
You could specialize shouldSaveFeature manually, but you should also be
sure you're solving a problem that really needs to be solved.
>>
>> Cheers,
>> Stefan
>>
>>
>
Re: Explicitly storing default values in XML resources [message #638323 is a reply to message #638270] Wed, 10 November 2010 20:42 Go to previous messageGo to next message
Heiko Ahlig is currently offline Heiko Ahlig
Messages: 62
Registered: July 2009
Member
Hi,
I had have the same problem sometimes and now I set all values.

I had have the problems with missing values, if I try to parse the
generated xml file with other xml parsers, where you evertime want a
value (default or not).

Maybee, Stefan have this usecase, too ?


Am 10.11.2010 15:58, schrieb Ed Merks:
> Stefan,
>
> Comments below.
>
> Stefan Winkler wrote:
>> Hi again,
>>
>> Used the debugger I have gained a few more insights.
>>
>> First, better than changing doSave() in the editor is actually adding
>> the option to the defaultSaveOptions of the generated ResourceImpl for
>> my XML file.
>>
>> Second, the problem seems to be that the defaultFeatureValueLiteral of
>> the affected features is null, which is why
>> XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
>> question is, why does the property view show a concrete value for the
>> boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
>> unset feature with a null default and does not save it.
> It's impossible for a primitive value to be null. EEnums are treated by
> EMF like primitives.
>>
>> I guess, I could work around this issue by changing my xsd2ecore map
>> and set proper default values everywhere. But my question remains: Why
>> is the property view and the saved resource inconsistent?
> The properties view shows the logical value. The same one returned by
> calling the getter...
>>
>> Cheers,
>> Stefan
>>
>>
>>
>> Am 09.11.10 18:04, schrieb Stefan Winkler:
>>> Hi,
>>>
>>> I have tried generating an EMF editor to edit XML instances of a given
>>> (rather complex) XSD file today. I created a genmodel from the XSD and
>>> then generated all the model, edit and editor code. Everything worked
>>> out of the box. This is way cool!
>>>
>>> My only problem is that when I create model instances with the generated
>>> editor, default values of booleans or enums are not stored in the
>>> resulting XML file.
> I'd expect that. I wonder why you consider that a problem? The whole
> point of default values in a schema is so that the actually instances
> don't need to contain such a value in order for it to be the "effective
> value."
>>> I did a search for this topic and found out about
>>> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the generated
>>> editors doSave() method and added this option at the beginning. This
>>> seems to be the correct point to do this (I have tried out the
>>> OPTION_FORMATTED option as well, and it behaves as expected).
>>> Also, when I set a property to some non-default value, save, and then
>>> set it back to the default, it keeps being stored in the XML file.
>>> However, unmodified default values are not stored, apparently.
> As the option says, it only keeps explicit defaults, not intrinsic
> defaults. (E.g., zero for the primitive numeric types).
>>>
>>> Of course, I do not want to modify each enum-based property once for
>>> every model, so: is there a way to achieve what I want? Did I do or
>>> understand anything wrong?
> You could specialize shouldSaveFeature manually, but you should also be
> sure you're solving a problem that really needs to be solved.
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>
Re: Explicitly storing default values in XML resources [message #638329 is a reply to message #638323] Wed, 10 November 2010 21:15 Go to previous messageGo to next message
Thomas Schindl is currently offline Thomas Schindl
Messages: 5321
Registered: July 2009
Senior Member
Shouldn't the XML-Parser fill in this default value based upon the XSD/DTD?

Tom

Am 10.11.10 21:42, schrieb Heiko Ahlig:
> Hi,
> I had have the same problem sometimes and now I set all values.
>
> I had have the problems with missing values, if I try to parse the
> generated xml file with other xml parsers, where you evertime want a
> value (default or not).
>
> Maybee, Stefan have this usecase, too ?
>
>
> Am 10.11.2010 15:58, schrieb Ed Merks:
>> Stefan,
>>
>> Comments below.
>>
>> Stefan Winkler wrote:
>>> Hi again,
>>>
>>> Used the debugger I have gained a few more insights.
>>>
>>> First, better than changing doSave() in the editor is actually adding
>>> the option to the defaultSaveOptions of the generated ResourceImpl for
>>> my XML file.
>>>
>>> Second, the problem seems to be that the defaultFeatureValueLiteral of
>>> the affected features is null, which is why
>>> XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
>>> question is, why does the property view show a concrete value for the
>>> boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
>>> unset feature with a null default and does not save it.
>> It's impossible for a primitive value to be null. EEnums are treated by
>> EMF like primitives.
>>>
>>> I guess, I could work around this issue by changing my xsd2ecore map
>>> and set proper default values everywhere. But my question remains: Why
>>> is the property view and the saved resource inconsistent?
>> The properties view shows the logical value. The same one returned by
>> calling the getter...
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>> Am 09.11.10 18:04, schrieb Stefan Winkler:
>>>> Hi,
>>>>
>>>> I have tried generating an EMF editor to edit XML instances of a given
>>>> (rather complex) XSD file today. I created a genmodel from the XSD and
>>>> then generated all the model, edit and editor code. Everything worked
>>>> out of the box. This is way cool!
>>>>
>>>> My only problem is that when I create model instances with the
>>>> generated
>>>> editor, default values of booleans or enums are not stored in the
>>>> resulting XML file.
>> I'd expect that. I wonder why you consider that a problem? The whole
>> point of default values in a schema is so that the actually instances
>> don't need to contain such a value in order for it to be the "effective
>> value."
>>>> I did a search for this topic and found out about
>>>> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the
>>>> generated
>>>> editors doSave() method and added this option at the beginning. This
>>>> seems to be the correct point to do this (I have tried out the
>>>> OPTION_FORMATTED option as well, and it behaves as expected).
>>>> Also, when I set a property to some non-default value, save, and then
>>>> set it back to the default, it keeps being stored in the XML file.
>>>> However, unmodified default values are not stored, apparently.
>> As the option says, it only keeps explicit defaults, not intrinsic
>> defaults. (E.g., zero for the primitive numeric types).
>>>>
>>>> Of course, I do not want to modify each enum-based property once for
>>>> every model, so: is there a way to achieve what I want? Did I do or
>>>> understand anything wrong?
>> You could specialize shouldSaveFeature manually, but you should also be
>> sure you're solving a problem that really needs to be solved.
>>>>
>>>> Cheers,
>>>> Stefan
>>>>
>>>>
>>>
Re: Explicitly storing default values in XML resources [message #638330 is a reply to message #638323] Wed, 10 November 2010 21:16 Go to previous messageGo to next message
Ed Merks is currently offline Ed Merks
Messages: 26048
Registered: July 2009
Senior Member
Heiko,

Adding default values to the schema and/or Ecore model and using the
option already described does already solve the problem.


Heiko Ahlig wrote:
> Hi,
> I had have the same problem sometimes and now I set all values.
>
> I had have the problems with missing values, if I try to parse the
> generated xml file with other xml parsers, where you evertime want a
> value (default or not).
>
> Maybee, Stefan have this usecase, too ?
>
>
> Am 10.11.2010 15:58, schrieb Ed Merks:
>> Stefan,
>>
>> Comments below.
>>
>> Stefan Winkler wrote:
>>> Hi again,
>>>
>>> Used the debugger I have gained a few more insights.
>>>
>>> First, better than changing doSave() in the editor is actually adding
>>> the option to the defaultSaveOptions of the generated ResourceImpl for
>>> my XML file.
>>>
>>> Second, the problem seems to be that the defaultFeatureValueLiteral of
>>> the affected features is null, which is why
>>> XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
>>> question is, why does the property view show a concrete value for the
>>> boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
>>> unset feature with a null default and does not save it.
>> It's impossible for a primitive value to be null. EEnums are treated by
>> EMF like primitives.
>>>
>>> I guess, I could work around this issue by changing my xsd2ecore map
>>> and set proper default values everywhere. But my question remains: Why
>>> is the property view and the saved resource inconsistent?
>> The properties view shows the logical value. The same one returned by
>> calling the getter...
>>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>
>>> Am 09.11.10 18:04, schrieb Stefan Winkler:
>>>> Hi,
>>>>
>>>> I have tried generating an EMF editor to edit XML instances of a given
>>>> (rather complex) XSD file today. I created a genmodel from the XSD and
>>>> then generated all the model, edit and editor code. Everything worked
>>>> out of the box. This is way cool!
>>>>
>>>> My only problem is that when I create model instances with the
>>>> generated
>>>> editor, default values of booleans or enums are not stored in the
>>>> resulting XML file.
>> I'd expect that. I wonder why you consider that a problem? The whole
>> point of default values in a schema is so that the actually instances
>> don't need to contain such a value in order for it to be the "effective
>> value."
>>>> I did a search for this topic and found out about
>>>> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the
>>>> generated
>>>> editors doSave() method and added this option at the beginning. This
>>>> seems to be the correct point to do this (I have tried out the
>>>> OPTION_FORMATTED option as well, and it behaves as expected).
>>>> Also, when I set a property to some non-default value, save, and then
>>>> set it back to the default, it keeps being stored in the XML file.
>>>> However, unmodified default values are not stored, apparently.
>> As the option says, it only keeps explicit defaults, not intrinsic
>> defaults. (E.g., zero for the primitive numeric types).
>>>>
>>>> Of course, I do not want to modify each enum-based property once for
>>>> every model, so: is there a way to achieve what I want? Did I do or
>>>> understand anything wrong?
>> You could specialize shouldSaveFeature manually, but you should also be
>> sure you're solving a problem that really needs to be solved.
>>>>
>>>> Cheers,
>>>> Stefan
>>>>
>>>>
>>>
Re: Explicitly storing default values in XML resources [message #638331 is a reply to message #638329] Wed, 10 November 2010 21:17 Go to previous message
Ed Merks is currently offline Ed Merks
Messages: 26048
Registered: July 2009
Senior Member
This is a multi-part message in MIME format.
--------------010706050902080709080207
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 7bit

Tom,

Yes, but only a schema-aware parser and then only default values
explicitly in the schema.


Tom Schindl wrote:
> Shouldn't the XML-Parser fill in this default value based upon the XSD/DTD?
>
> Tom
>
> Am 10.11.10 21:42, schrieb Heiko Ahlig:
>
>> Hi,
>> I had have the same problem sometimes and now I set all values.
>>
>> I had have the problems with missing values, if I try to parse the
>> generated xml file with other xml parsers, where you evertime want a
>> value (default or not).
>>
>> Maybee, Stefan have this usecase, too ?
>>
>>
>> Am 10.11.2010 15:58, schrieb Ed Merks:
>>
>>> Stefan,
>>>
>>> Comments below.
>>>
>>> Stefan Winkler wrote:
>>>
>>>> Hi again,
>>>>
>>>> Used the debugger I have gained a few more insights.
>>>>
>>>> First, better than changing doSave() in the editor is actually adding
>>>> the option to the defaultSaveOptions of the generated ResourceImpl for
>>>> my XML file.
>>>>
>>>> Second, the problem seems to be that the defaultFeatureValueLiteral of
>>>> the affected features is null, which is why
>>>> XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
>>>> question is, why does the property view show a concrete value for the
>>>> boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
>>>> unset feature with a null default and does not save it.
>>>>
>>> It's impossible for a primitive value to be null. EEnums are treated by
>>> EMF like primitives.
>>>
>>>> I guess, I could work around this issue by changing my xsd2ecore map
>>>> and set proper default values everywhere. But my question remains: Why
>>>> is the property view and the saved resource inconsistent?
>>>>
>>> The properties view shows the logical value. The same one returned by
>>> calling the getter...
>>>
>>>> Cheers,
>>>> Stefan
>>>>
>>>>
>>>>
>>>> Am 09.11.10 18:04, schrieb Stefan Winkler:
>>>>
>>>>> Hi,
>>>>>
>>>>> I have tried generating an EMF editor to edit XML instances of a given
>>>>> (rather complex) XSD file today. I created a genmodel from the XSD and
>>>>> then generated all the model, edit and editor code. Everything worked
>>>>> out of the box. This is way cool!
>>>>>
>>>>> My only problem is that when I create model instances with the
>>>>> generated
>>>>> editor, default values of booleans or enums are not stored in the
>>>>> resulting XML file.
>>>>>
>>> I'd expect that. I wonder why you consider that a problem? The whole
>>> point of default values in a schema is so that the actually instances
>>> don't need to contain such a value in order for it to be the "effective
>>> value."
>>>
>>>>> I did a search for this topic and found out about
>>>>> the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the
>>>>> generated
>>>>> editors doSave() method and added this option at the beginning. This
>>>>> seems to be the correct point to do this (I have tried out the
>>>>> OPTION_FORMATTED option as well, and it behaves as expected).
>>>>> Also, when I set a property to some non-default value, save, and then
>>>>> set it back to the default, it keeps being stored in the XML file.
>>>>> However, unmodified default values are not stored, apparently.
>>>>>
>>> As the option says, it only keeps explicit defaults, not intrinsic
>>> defaults. (E.g., zero for the primitive numeric types).
>>>
>>>>> Of course, I do not want to modify each enum-based property once for
>>>>> every model, so: is there a way to achieve what I want? Did I do or
>>>>> understand anything wrong?
>>>>>
>>> You could specialize shouldSaveFeature manually, but you should also be
>>> sure you're solving a problem that really needs to be solved.
>>>
>>>>> Cheers,
>>>>> Stefan
>>>>>
>>>>>
>>>>>
>
>

--------------010706050902080709080207
Content-Type: text/html; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-15"
http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Tom,<br>
<br>
Yes, but only a schema-aware parser and then only default values
explicitly in the schema.<br>
<br>
<br>
Tom Schindl wrote:
<blockquote cite="mid:ibf1q1$454$1@news.eclipse.org" type="cite">
<pre wrap="">Shouldn't the XML-Parser fill in this default value based upon the XSD/DTD?

Tom

Am 10.11.10 21:42, schrieb Heiko Ahlig:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,
I had have the same problem sometimes and now I set all values.

I had have the problems with missing values, if I try to parse the
generated xml file with other xml parsers, where you evertime want a
value (default or not).

Maybee, Stefan have this usecase, too ?


Am 10.11.2010 15:58, schrieb Ed Merks:
</pre>
<blockquote type="cite">
<pre wrap="">Stefan,

Comments below.

Stefan Winkler wrote:
</pre>
<blockquote type="cite">
<pre wrap="">Hi again,

Used the debugger I have gained a few more insights.

First, better than changing doSave() in the editor is actually adding
the option to the defaultSaveOptions of the generated ResourceImpl for
my XML file.

Second, the problem seems to be that the defaultFeatureValueLiteral of
the affected features is null, which is why
XMLSaveImpl.shouldSaveFeature returns false in these cases. So, the
question is, why does the property view show a concrete value for the
boolean or enum-typed EAttributes but the actual XMLSaveImpl sees an
unset feature with a null default and does not save it.
</pre>
</blockquote>
<pre wrap="">It's impossible for a primitive value to be null. EEnums are treated by
EMF like primitives.
</pre>
<blockquote type="cite">
<pre wrap="">I guess, I could work around this issue by changing my xsd2ecore map
and set proper default values everywhere. But my question remains: Why
is the property view and the saved resource inconsistent?
</pre>
</blockquote>
<pre wrap="">The properties view shows the logical value. The same one returned by
calling the getter...
</pre>
<blockquote type="cite">
<pre wrap="">Cheers,
Stefan



Am 09.11.10 18:04, schrieb Stefan Winkler:
</pre>
<blockquote type="cite">
<pre wrap="">Hi,

I have tried generating an EMF editor to edit XML instances of a given
(rather complex) XSD file today. I created a genmodel from the XSD and
then generated all the model, edit and editor code. Everything worked
out of the box. This is way cool!

My only problem is that when I create model instances with the
generated
editor, default values of booleans or enums are not stored in the
resulting XML file.
</pre>
</blockquote>
</blockquote>
<pre wrap="">I'd expect that. I wonder why you consider that a problem? The whole
point of default values in a schema is so that the actually instances
don't need to contain such a value in order for it to be the "effective
value."
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I did a search for this topic and found out about
the XMLResource.OPTION_KEEP_DEFAULT_CONTENT. So I modified the
generated
editors doSave() method and added this option at the beginning. This
seems to be the correct point to do this (I have tried out the
OPTION_FORMATTED option as well, and it behaves as expected).
Also, when I set a property to some non-default value, save, and then
set it back to the default, it keeps being stored in the XML file.
However, unmodified default values are not stored, apparently.
</pre>
</blockquote>
</blockquote>
<pre wrap="">As the option says, it only keeps explicit defaults, not intrinsic
defaults. (E.g., zero for the primitive numeric types).
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Of course, I do not want to modify each enum-based property once for
every model, so: is there a way to achieve what I want? Did I do or
understand anything wrong?
</pre>
</blockquote>
</blockquote>
<pre wrap="">You could specialize shouldSaveFeature manually, but you should also be
sure you're solving a problem that really needs to be solved.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">Cheers,
Stefan


</pre>
</blockquote>
</blockquote>
</blockquote>
</blockquote>
<pre wrap=""><!---->
</pre>
</blockquote>
</body>
</html>

--------------010706050902080709080207--
Previous Topic:Access EMF generated classes from JEE remote client
Next Topic:Sorted ELists
Goto Forum:
  


Current Time: Thu Sep 18 01:48:41 GMT 2014

Powered by FUDForum. Page generated in 0.04545 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software