these slides give a short overview of the new myfaces extval v1.x.2 features.
Sunday, April 26, 2009
Monday, April 20, 2009
release of myfaces-extensions-validator
the apache myfaces team is pleased to announce a new release of myfaces-extensions-validator!
released versions:
extval 1.1.2 (for jsf 1.1.x)
extval 1.2.2 (for jsf 1.2.x)
Wednesday, April 15, 2009
[updated] myfaces-extval config extension
extval 1.x.2 provides some new mechanisms. therefore the annotation based config also provides some new annotations.
new annotations:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
extval allows name mappers for different areas. @NameMapper makes it easy to provide a custom name mapping strategies. the following screenshot shows an example how to use @NameMapper
new annotations:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
extval allows name mappers for different areas. @NameMapper makes it easy to provide a custom name mapping strategies. the following screenshot shows an example how to use @NameMapper
myfaces-extval-add-on - @SecuredAction
you might already know that you can use myfaces extval for much more than validation. this new add-on shows how simple it is to provide add-ons for different problem domains. it's available at http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/secure_actions.
@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.
the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.
@SecuredAction offers several features - here are some short examples:
that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.
the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:
it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:
furthermore, in case of denied access, you can automatically add a (global) error message via:
the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:
//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");
//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");
in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role
the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.
it's also possible to define specific pages which need a secured action method:
to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:
@SecuredAction is an annotation to secure the execution of action methods. it's independent of the concrete command component and offers several features. normally you can secure such actions via the rendered attribute. however, maybe you would like to restrict method execution based on new model values (which were updated at the same request). there are several other use-cases where you can use it instead of the required attribute of the command component. at least it is a feasibility study for further extval add-ons.
the base idea is similar to the @RolesAllowed of tobago. this extval-add-on offers a bit more than a role check. if you are just interested in the same functionality without using tobago, it's quite easy to add an "allowedRoles"-attribute as well. it isn't implemented out-of-the-box, because the existing approach of permittedIf-conditions is much more generic.
@SecuredAction offers several features - here are some short examples:
that means:
if one of the condition(s) returns false the "deny"-method is called instead of the annotated method. also the optional return-value is used as expected. so you can execute custom logic in case of denied access.
the following example shows a shorter syntax for the "deny"-method. it's possible to refer a local method directly:
it's also possible to overrule the outcome. the following example forces to redisplay the same page instead of displaying a different one:
furthermore, in case of denied access, you can automatically add a (global) error message via:
the add-on automatically looks at the same package of the class (which hosts the secured action method(s)). the name of the resource bundle is: securty_messages. it's just for demo cases. for real word usages you can register e.g. an existing bundle within an extval-startup listener. you can register a message-bundle base-name or for jsf 1.2+ also a message-bundle var-name.
sample:
//use an existing message bundle
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "at.gp.demos.messages.my_messages");
//use an existing message bundle var-name
ExtValContext.getContext().addGlobalProperty(
SecuredAction.MESSAGE_BUNDLE, "#{myMessages}");
in the message bundle you have to add a summary and detail message - e.g.:
action_not_allowed = action not allowed
action_not_allowed_detail = action not allowed - please switch the role
the default case is that @SecuredAction doesn't change the lifecycle execution. via an additional attribute it's possible to change that. the following example always leads to an execution (of the secureAction) in the "apply requests values"-phase. if it's permitted to call the secured method, the original lifecycle execution also doesn't change in this case.
it's also possible to define specific pages which need a secured action method:
to define different scenarios, it's possible to use multiple annotations at one method. you can do that via:
Tuesday, April 7, 2009
myfaces-extval and prime faces
today i tested extval in combination with primefaces. it worked without modifications. i just added:
- myfaces-extval-core
- myfaces-extval-property-validation
- myfaces-extval-core
- myfaces-extval-property-validation
Thursday, April 2, 2009
myfaces-extval for highlighting validated fields without additional/special components
you can find a short demo case for highlighting validated fields without additional/special components at example 105
the result looks like:
the result looks like:
Tuesday, March 31, 2009
myfaces-extval-add-on - @BypassValidationController
the bypass validation add-on for extval was updated!
beyond the action-method based bypass it's possible to bypass validation with an annotation which is similar to a view-controller annotation. anyway, it works the opposite way round. if the annotation is used validation is bypassed.
you can use the annotation on the first bean (= page/backing bean), the first property (of the page/backing bean), the last base object (owner of the property) and the bound property.
that means something like:
#{pageBean.bean1.bean2.person.firstName}
the green parts are possible targets for @BypassValidationController
a simple example:
that leads to:
1) bypassed extval-validation for every property bound via: #{personPage2. ...}
attention: only skipable validations are bypassed by default. so e.g. jpa based validation continues to work. if you would like to really bypass everything, you have to use:
@BypassValidationController(@ViewId(all = true))
instead.
2) bypassed extval-validation for every property bound via: #{personPage2.person ...}
but only for the view-id "/pages/new_person2.xhtml" + the given condition is true.
it's important to mention that the 4 possible targets for @BypassValidationController are optional. e.g. it's possible to annotate a property without annotating the class itself. furthermore, there are useful default values for all attributes.
beyond the action-method based bypass it's possible to bypass validation with an annotation which is similar to a view-controller annotation. anyway, it works the opposite way round. if the annotation is used validation is bypassed.
you can use the annotation on the first bean (= page/backing bean), the first property (of the page/backing bean), the last base object (owner of the property) and the bound property.
that means something like:
#{pageBean.bean1.bean2.person.firstName}
the green parts are possible targets for @BypassValidationController
a simple example:
that leads to:1) bypassed extval-validation for every property bound via: #{personPage2. ...}
attention: only skipable validations are bypassed by default. so e.g. jpa based validation continues to work. if you would like to really bypass everything, you have to use:
@BypassValidationController(@ViewId(all = true))
instead.
2) bypassed extval-validation for every property bound via: #{personPage2.person ...}
but only for the view-id "/pages/new_person2.xhtml" + the given condition is true.
it's important to mention that the 4 possible targets for @BypassValidationController are optional. e.g. it's possible to annotate a property without annotating the class itself. furthermore, there are useful default values for all attributes.
myfaces-extval and icefaces
i did some quick tests with icefaces and extval.
behind the scenes icefaces does some tricks.
so it's required to deactivate 2 extval mechanisms. with this workaround a hello world icesfaces started working with myfaces extval.
#1: deactivate the extval el-resolver via web.xml context-parameter:
org.apache.myfaces.extensions.validator.DEACTIVATE_EL_RESOLVER
true
#2 switch or deactivate the default renderer proxy implementation via a extval-startup-listener.
deactivate it via:
...
protected void init()
{
ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, null);
}
...
i haven't tried more complex applications. you are welcome to try it out :)
if you find some issues please report them.
behind the scenes icefaces does some tricks.
so it's required to deactivate 2 extval mechanisms. with this workaround a hello world icesfaces started working with myfaces extval.
#1: deactivate the extval el-resolver via web.xml context-parameter:
#2 switch or deactivate the default renderer proxy implementation via a extval-startup-listener.
deactivate it via:
...
protected void init()
{
ExtValContext.getContext().addGlobalProperty(ExtValRendererProxy.KEY, null);
}
...
i haven't tried more complex applications. you are welcome to try it out :)
if you find some issues please report them.
Thursday, March 5, 2009
myfaces-extval-add-on - @BypassValidation for action methods
there is a new add-on for myfaces-extval.
it's hosted at [1] and a sample application is available at [2].
[intro]
normally you have to validate all bound properties.
extval provides out-of-the-box a skip validation feature.
if one of the expressions of @SkipValidation returns true, validation of skipable validators gets canceled (the validation strategy has to be marked with @SkipValidationSupport).
anyway, sometimes you need actions which aren't immediate but they have to get executed without validation. therefore this add-on provides @BypassValidation
[new]
just add the add-on to your classpath and annotate these special action methods - example:
@BypassValidation
this simple case bypasses all skipable validations, if the annotated action method will be called.
-> e.g.: in this case @Required doesn't get validated whereas db constraints like nullable = false and length are validated in any case. (see the next usage, if you would like to bypass everything. however, please notice that it might lead to an exception if you try to save an invalid entity. so it's better to use all = false)
if you would like to bypass all validations use:
@BypassValidation(all = true)
furthermore, you can provide one or more optional el-expressions.
so it is possible to bypass validation just if one of the conditions returns true.
@BypassValidation(
condition="#{currentUserRole.privileged}")
requirements: myfaces-extval 1.x.2-SNAPSHOT+
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/bypass_validation
[2] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples/basic/demo_009
it's hosted at [1] and a sample application is available at [2].
[intro]
normally you have to validate all bound properties.
extval provides out-of-the-box a skip validation feature.
if one of the expressions of @SkipValidation returns true, validation of skipable validators gets canceled (the validation strategy has to be marked with @SkipValidationSupport).
anyway, sometimes you need actions which aren't immediate but they have to get executed without validation. therefore this add-on provides @BypassValidation
[new]
just add the add-on to your classpath and annotate these special action methods - example:
@BypassValidation
this simple case bypasses all skipable validations, if the annotated action method will be called.
-> e.g.: in this case @Required doesn't get validated whereas db constraints like nullable = false and length are validated in any case. (see the next usage, if you would like to bypass everything. however, please notice that it might lead to an exception if you try to save an invalid entity. so it's better to use all = false)
if you would like to bypass all validations use:
@BypassValidation(all = true)
furthermore, you can provide one or more optional el-expressions.
so it is possible to bypass validation just if one of the conditions returns true.
@BypassValidation(
condition="#{currentUserRole.privileged}")
requirements: myfaces-extval 1.x.2-SNAPSHOT+
[1] http://code.google.com/p/
[2] http://code.google.com/p/
Monday, February 23, 2009
myfaces-extval vs seam 2.x integration of hibernate validator - a first draft
here you see a first draft of the comparison myfaces-extval vs. the seam 2.x integration of hibernate validator (currently hibernate validator v4 is still alpha. so it isn't compared here).
hibernate validator v4 will be the ri-implementation of jsr 303. myfaces-extval will also provide an integration module to use a jsr 303 implementation with all jsf versions.
it's just a first draft. please don't get me wrong. it shouldn't be a statement against seam or hibernate validator. both frameworks are nice. however, that's how it looks like at the current state. the goal is just to have a correct side-by-side comparison of the available features. so please contact me, if you think that the seam side provides a feature i might have missed so far. i'll correct it.
Thursday, February 12, 2009
principles of myfaces-extval
this picture illustrates the base principles of extval:
- no special requirements for meta-data
- support of existing jsf component libs
- compatible with existing and future java ee standards
- extensible and customizable (custom add-ons)
- no special requirements for meta-data
- support of existing jsf component libs
- compatible with existing and future java ee standards
- extensible and customizable (custom add-ons)
Tuesday, January 27, 2009
myfaces-extval introduction slides
These slides introduce MyFaces Extensions Validator. This first part is a short overview. To get more information about MyFaces Extensions Validator we also offer slides with all important details you need to use and customize MyFaces ExtVal. Do not hesitate to contact us!
Tuesday, January 20, 2009
Saturday, January 17, 2009
myfaces-extval examples available
the os890 project offers several examples [1] which illustrate different myfaces extval features. they also show different approaches to solve common requirements (sometimes multiple approaches per requirement). beside some comments each example contains a README.txt which summarizes the illustrated features of the example. an overview is available at [2].
besides these examples extval itself also provides examples at [3] [4]
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples
[2] http://code.google.com/p/os890/wiki/MyFaces_Extensions_Validator_Example_Overview
[3] http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/
[4] http://apache.org/dist/myfaces/binaries/
besides these examples extval itself also provides examples at [3] [4]
[1] http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/examples
[2] http://code.google.com/p/os890/wiki/MyFaces_Extensions_Validator_Example_Overview
[3] http://svn.apache.org/repos/asf/myfaces/extensions/validator/trunk/examples/
[4] http://apache.org/dist/myfaces/binaries/
Friday, December 12, 2008
1st release of myfaces-extensions-validator
the apache myfaces team is pleased to announce the first release of myfaces-extensions-validator!
released versions:
extval 1.1.1 (for jsf 1.1.x)
extval 1.2.1 (for jsf 1.2.x)
Friday, October 24, 2008
myfaces-extval config extension
there's a new external module for myfaces-extval.
it provides an alternative configuration approach for extval.
this extension allows to configure the following artifacts via annotations:
- StartupListener
- ValidationStrategy
- MessageResolver
- ComponentInitializer
- MetaDataTransformer
- InformationProviderBean
- ProcessedInformationRecorder
- RendererInterceptor
since extval 1.x.2:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
you will find further details in the provided README.txt
it's available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/annotation_based_config
it provides an alternative configuration approach for extval.
this extension allows to configure the following artifacts via annotations:
- StartupListener
- ValidationStrategy
- MessageResolver
- ComponentInitializer
- MetaDataTransformer
- InformationProviderBean
- ProcessedInformationRecorder
- RendererInterceptor
since extval 1.x.2:
- MetaDataExtractionInterceptor
- NameMapper
- FacesMessageFactory
you will find further details in the provided README.txt
it's available at:
http://code.google.com/p/os890/source/browse/#svn/trunk/java/web/jsf/extval/annotation_based_config
Thursday, September 25, 2008
myfaces-extval meets myfaces-trinidad
yesterday i added a much better trinidad support.
all parts of the trinidad support are available within an own module.
to enable the trinidad support you just have to add
myfaces-extval-trinidad-support-1.*.jar
to the classpath.
it provides e.g. client-side validation. this means that client-side trinidad validation gets based on annotations (the simple extval annotations and jpa annotations). it's also possible to use client-side validation based on custom annotations. moreover, this approach allows to reuse implementations of existing client-side trinidad validators.
the trinidad support shows how extval is able to use client-side validation features of component libs in a very easy way.
all parts of the trinidad support are available within an own module.
to enable the trinidad support you just have to add
myfaces-extval-trinidad-support-1.*.jar
to the classpath.
it provides e.g. client-side validation. this means that client-side trinidad validation gets based on annotations (the simple extval annotations and jpa annotations). it's also possible to use client-side validation based on custom annotations. moreover, this approach allows to reuse implementations of existing client-side trinidad validators.
the trinidad support shows how extval is able to use client-side validation features of component libs in a very easy way.
Tuesday, September 16, 2008
myfaces-extval got independent of cglib
some days ago i introduced a new mechanism which replaces the cglib approach.
so some proxy drawbacks of the old approach are solved.
so some proxy drawbacks of the old approach are solved.
what changes for the user:
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
you just have to check the compatibility with your component lib.
old:
requirement of the cglib approach:
component and converter creation via the jsf application.
new:
requirement of the new approach:
all input components have to call the method getConvertedValue.
(a method of javax.faces.render.Renderer)
what's the workaround, if a component lib doesn't do that so far?
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
it's still possible to use the cglib approach or the adapter fallback approach of the alternative module.
how do i reactivate the cglib approach?
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
just add myfaces-extval-alternative-1.x.x-SNAPSHOT.jar to the classpath.
that's it!
Monday, July 14, 2008
myfaces-extval and myfaces-core12 < v1.2.4
myfaces core12 < v1.2.4 has a bug. a workaround to use extval with these versions is available at http://code.google.com/p/os890/source/browse/trunk/java/web/jsf/extval/myfaces-core12-workaround/CrossValidationMyFacesFixPhaseListener.java
information for users of myfaces-core 1.2.4+ don't need this workaround for these releases.
information for users of myfaces-core 1.2.4+ don't need this workaround for these releases.
sev-en continues at myfaces
today i imported the refactored implementation of sev-en into the upcoming myfaces-extensions project. the official name is myfaces-extensions-validator. however, i'll use the abbreviation myfaces-extval.
Sunday, June 8, 2008
sev-en meets myfaces
some weeks ago we (the myfaces community) decided to add sev-en.
last week there was a successful vote that there will be a new sub-project called myfaces-extensions.
myfaces-extensions will contain:
- myfaces-extensions-aspectel
- myfaces-extensions-validator (aka sev-en)
- myfaces-extensions-scripting
last week there was a successful vote that there will be a new sub-project called myfaces-extensions.
myfaces-extensions will contain:
- myfaces-extensions-aspectel
- myfaces-extensions-validator (aka sev-en)
- myfaces-extensions-scripting
Tuesday, April 15, 2008
sev-en preview - new version
within the last few days i refactored sev-en. the most significant change: sev-en doesn't need the generated adapters.
Monday, April 7, 2008
sev-en preview - re-use existing annotations
today i added a new annotation to the previous example.
within the page-bean-class:
so you don't have to repeat all annotations of the domain-class within the page-bean.
within the domain-class:
within the page-bean-class:
so you don't have to repeat all annotations of the domain-class within the page-bean.
within the domain-class:
Friday, April 4, 2008
sev-en preview - first public demo
i uploaded the intermediate result of the sev-en demo at:
http://people.apache.org/~gpetracek/myfaces/extval/
http://people.apache.org/~gpetracek/myfaces/extval/
Wednesday, April 2, 2008
sev-en preview - a short example
as mentioned within the previous post:
sev-en has zero required configuration and offers some powerful features such as cross-component validation and extensibility (e.g.: easy custom validation).
the following part illustrates some of these features.
the example uses facelets and trinidad. however, these technologies are not required!
(sev-en supports property and field access.)
sample scenario - the target:
=> first name != last name
=> birthday is (of course) before the final exam
=> old nick name != new nick name (with a direct reference to the old value)
=> old password != new password (without a direct reference to the old value)
=> new password == re-entered new password
=> each input-field is required (within the domain model: re-use jpa annotations)
=> restrict the max. length of string values (also re-use information of jpa annotations)
now hold on a moment and think about the effort of doing such validations.
without sev-en:
the simple parts of the scenario above can be solved with the according tags. if you are using jpa annotations, you already have some of these information within your mapping. -> redundancy (annotations + tags).
ok - let's have a look at the more complex validation scenarios. i'm referring to the date and password validations. there might be e.g. some password components available. does your component lib offer such a feature? ok - nice, if you are one of the lucky one's. however, what's about the next complex requirement within your project? - there might be no adequate component within the available component libs.
or are you using one of the unaesthetic workarounds?
sev-en provides a lot of powerful solutions.
using sev-en:
the registration page:
the page to change the nick name:
the page to change the password:
... oh - it's really straightforward!
the page bean class (backing bean):
... oh - some new annotations - however, it's also really straightforward!
we aren't using jpa annotations here (it's the view layer!)
the domain model class:
... really nice - some simple jpa annotations which are also used for validation.
you aren't using jpa? no problem - you can use conventional validation and/or you can use the sev-en standard or custom annotations ;)
the following screenshot shows an example of a failed validation:
sev-en isn't about specific annotations. sev-en is mainly the core itself. out-of-the-box sev-en will provide some separated modules with nice annotations.
one of the next posts will be about the really easy way to implement custom sev-en annotations.
sev-en has zero required configuration and offers some powerful features such as cross-component validation and extensibility (e.g.: easy custom validation).
the following part illustrates some of these features.
the example uses facelets and trinidad. however, these technologies are not required!
(sev-en supports property and field access.)
sample scenario - the target:
=> first name != last name
=> birthday is (of course) before the final exam
=> old nick name != new nick name (with a direct reference to the old value)
=> old password != new password (without a direct reference to the old value)
=> new password == re-entered new password
=> each input-field is required (within the domain model: re-use jpa annotations)
=> restrict the max. length of string values (also re-use information of jpa annotations)
now hold on a moment and think about the effort of doing such validations.
without sev-en:
the simple parts of the scenario above can be solved with the according tags. if you are using jpa annotations, you already have some of these information within your mapping. -> redundancy (annotations + tags).
ok - let's have a look at the more complex validation scenarios. i'm referring to the date and password validations. there might be e.g. some password components available. does your component lib offer such a feature? ok - nice, if you are one of the lucky one's. however, what's about the next complex requirement within your project? - there might be no adequate component within the available component libs.
or are you using one of the unaesthetic workarounds?
sev-en provides a lot of powerful solutions.
using sev-en:
the registration page:
the page to change the nick name:
the page to change the password:
... oh - it's really straightforward!
the page bean class (backing bean):
... oh - some new annotations - however, it's also really straightforward!
we aren't using jpa annotations here (it's the view layer!)
the domain model class:
... really nice - some simple jpa annotations which are also used for validation.
you aren't using jpa? no problem - you can use conventional validation and/or you can use the sev-en standard or custom annotations ;)
the following screenshot shows an example of a failed validation:
sev-en isn't about specific annotations. sev-en is mainly the core itself. out-of-the-box sev-en will provide some separated modules with nice annotations.
one of the next posts will be about the really easy way to implement custom sev-en annotations.
Monday, March 31, 2008
7 - my new jsf extension
today i presented the first preview of sev-en.
it stands for:
simple enhanced validation with extensible nature
the base idea was to start a feasibility study about annotation based jsf validation. e.g. it should be possible to re-use jpa annotations for validation.
last weekend i finished the first prototype.
current main-features:
- cross-component validation (including cross-entity validation)
- support for jpa based validation
- extensible (e.g. custom annotations and all important parts of the core)
- zero configuration
within the next view weeks i'll provide further details.
it stands for:
simple enhanced validation with extensible nature
the base idea was to start a feasibility study about annotation based jsf validation. e.g. it should be possible to re-use jpa annotations for validation.
last weekend i finished the first prototype.
current main-features:
- cross-component validation (including cross-entity validation)
- support for jpa based validation
- extensible (e.g. custom annotations and all important parts of the core)
- zero configuration
within the next view weeks i'll provide further details.
boot sequence finished successfully
initialize new blog...
boot sequence finished ................... [ok]
the open source blog of gerhard petracek
established successfully ................. [ok]
yes - yet another blog :)
boot sequence finished ................... [ok]
the open source blog of gerhard petracek
established successfully ................. [ok]
yes - yet another blog :)
Subscribe to:
Posts (Atom)