You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cocoon.apache.org by Carlos Martínez Peña <ca...@uib.es> on 2007/11/06 08:09:18 UTC
Information about hour field type
Hello,
I'm developing a typical form based aplication with cforms.
But now, i need one more field type. I need that user can put a hour
with cforms. It can be like data type field or using two selects, one
for hours and another one for minuts.
I don't know it is developing in the new releases or someone have
implemented it for some similar reason.
Thanks, Carlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Fop 0.93 in cocoon 2.1.9
Posted by Joerg Heinicke <jo...@gmx.de>.
On 30.11.2007 2:56 Uhr, Carlos Martínez wrote:
> I'm trying to run fop 0.93 in cocoon 2.1.9.
>
> I have added fop0.93.jar and xmlgraphics-commons-1.1.jar l to the
> WEB-INF\lib in my local instalation of cocoon, and remove the old jar
> versions. And when i try to use the fo2pdf serializer it show me this
> error.
The API of FOP has changed fundamentally between 0.20.5 and 0.9x. That's
why it does not work by just replacing the jars. What you can try though
is to use the FOP NG block which is only available in Cocoon 2.2. It
should be pretty straight forward to use it in Cocoon 2.1.
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Fop 0.93 in cocoon 2.1.9
Posted by Huib Verweij <hv...@be-value.nl>.
Hi Carlos,
recently I installed fop-0.94 and xmlgraphics-commons-1.2 into Cocoon
2.1.11 (svn version). That works, but only with a different Cocoon FOP
serializer which you can find here:
http://www.mail-archive.com/users@cocoon.apache.org/msg39164.html
Regards,
Huib Verweij.
On vr, 2007-11-30 at 08:56 +0100, Carlos Martínez wrote:
> I'm trying to run fop 0.93 in cocoon 2.1.9.
>
> I have added fop0.93.jar and xmlgraphics-commons-1.1.jar l to the
> WEB-INF\lib in my local instalation of cocoon, and remove the old jar
> versions. And when i try to use the fo2pdf serializer it show me this error.
>
> java.lang.NoClassDefFoundError: org/apache/fop/messaging/MessageHandler
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Fop 0.93 in cocoon 2.1.9
Posted by Carlos Martínez <ca...@uib.es>.
Hello,
I'm trying to run fop 0.93 in cocoon 2.1.9.
I have added fop0.93.jar and xmlgraphics-commons-1.1.jar l to the
WEB-INF\lib in my local instalation of cocoon, and remove the old jar
versions. And when i try to use the fo2pdf serializer it show me this error.
java.lang.NoClassDefFoundError: org/apache/fop/messaging/MessageHandler
Thanks, Carlos.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Getting Started Guide
Posted by Harald Entner <ha...@gmx.at>.
Have you created a project before?
e.g.
mvn archetype:create
-DarchetypeGroupId=org.apache.cocoon
-DarchetypeArtifactId=cocoon-22-archetype-block
-DarchetypeVersion=1.0.0-RC2
-DgroupId=com.mycompany
-DartifactId=myBlock1
This will created the project hierarchy as well as a valid pom.xml file.
after that you should be able to execute mvn eclipse:eclipse.
greets, harald
Robin Rigby schrieb:
> I have follwed the Getting Started Guide as far as Using the Reloading
> Classloader [1].
>
> ----
>
> I move to getting-started-app/ and invoke
>
> mvn eclipse:eclipse.
>
> I get
>
> "Cannot execute mojo: eclipse. It requires a project with an existing
> pom.xml, but the build is not using one."
>
> Am I in the wrong directory or have I missed an opportunity to create a POM?
>
> ----
>
> Also: the current version of cocoon-maven-plugin seems to be 1.0.0-M1, not
> 1.0.0-M1-SNAPSHOT.
>
> Also: throughout the Getting Started Guide, it is sometimes not clear in
> which dirctory I should invoke the various mvn commands. It becomes sort of
> instinctive after a while but only _after_ I have got started. :-)
>
> Thanks
>
> Robin
>
> [1]
> http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1
> 297_1_1.html
> 07785 765017
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Getting Started Guide
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Robin Rigby pisze:
> I have follwed the Getting Started Guide as far as Using the Reloading
> Classloader [1].
>
> ----
>
> I move to getting-started-app/ and invoke
>
> mvn eclipse:eclipse.
>
> I get
>
> "Cannot execute mojo: eclipse. It requires a project with an existing
> pom.xml, but the build is not using one."
>
> Am I in the wrong directory or have I missed an opportunity to create a POM?
I hope that hint from Harald will help you. If not, it would be good if you provide listing of
getting-started-app directory.
> ----
>
> Also: the current version of cocoon-maven-plugin seems to be 1.0.0-M1, not
> 1.0.0-M1-SNAPSHOT.
Fixed now and will be published shortly.
> Also: throughout the Getting Started Guide, it is sometimes not clear in
> which dirctory I should invoke the various mvn commands. It becomes sort of
> instinctive after a while but only _after_ I have got started. :-)
Yes, this tutorial could be more verbose and precise. I'll try to fix it in a free time.
Thanks for suggestions.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: own widget
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Michel Erard pisze:
> Hi,
>
> I'd like do implement an own widget, where the label is a link that opens a help page.
>
> Is it possible to implement a new widget, outside of the cocoon-forms block or do I have to
> extend this block? Is there a small tutorial, which classes I have to implement/overwrite?
>From what I can see you don't need to implement a completely new widget but only implement new
styling for existing one that will show label differently, right?
If so, you will just need to create a small XSLT file and integrate it with existing Forms
infrastructure. Before I'll give you concrete hints I would like to know which version of Cocoon you
use.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: AW: own widget
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Felix Knecht pisze:
> @Grzegorz
> I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't it make more sense to use already the
> new forms block instead of the legacy one (probably it makes configuration also easier)?
Yes, Giacomo migrated forms to Spring recently but there are still two problems:
1. There was no release of Forms 1.1.0
2. There is no migration guide or any other document describing how things changed and how
everything is going to work.
The second point is especially important and I'm little bit disappointed that others making
incompatible (but wholeheartedly wanted!) changes do not write any documentation. It's really not
hard to write migration guide but I believe it really helps our users. Am I wrong?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: AW: own widget
Posted by bart remmerie <re...@gmail.com>.
Dear Michel,
I've already implemented such a feature, not by creating a new widget, but
using the stylesheet-approach.
Basically, you create a new styling type "link" or "href-label" and include
it in the forms styling stylesheets.
The most difficult part is to create the "href" part of your hyperlink.
For an elegant solution, you should be able to define the hyperlink outside
the stylesheet.
You should be able to pass it as an argument through the form's template.
In my use case, I pass a 'fixed part', something like '/myhelppages/' + a
variable part linked to the id of the record. Where the id of the record is
a part of the object model, known within the form (as a hidden field) &
accessible in the stylesheet.
I know this may seem complicated, and if interested I can provide the
source-snippets.
Bart
2007/11/9, Michel Erard <mi...@corix.ch>:
>
> I already tested the trunk version of forms block and the only thing that
> changed for uses was that all 'class' attributes are replaced by 'ref' and
> take a spring bean as argument. And there is a new spring config file in the
> forms block of course.
>
> What do you think about a new Datatype 'object', that for example can be
> used to link persistent objects? Of course this feature would only make
> sense when you have a selection-list with a defined set of objects. Or maybe
> better an ObjectSelectionList?
>
>
>
>
> ________________________________
>
> Von: Grzegorz Kossakowski [mailto:gkossakowski@apache.org]
> Gesendet: Do 08.11.2007 18:57
> An: users@cocoon.apache.org
> Betreff: Re: AW: own widget
>
>
>
> Felix Knecht pisze:
> > @Grzegorz
> > I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't
> it make more sense to use already the
> > new forms block instead of the legacy one (probably it makes
> configuration also easier)?
>
> Yes, Giacomo migrated forms to Spring recently but there are still two
> problems:
> 1. There was no release of Forms 1.1.0
> 2. There is no migration guide or any other document describing how things
> changed and how
> everything is going to work.
>
> The second point is especially important and I'm little bit disappointed
> that others making
> incompatible (but wholeheartedly wanted!) changes do not write any
> documentation. It's really not
> hard to write migration guide but I believe it really helps our users. Am
> I wrong?
>
> --
> Grzegorz Kossakowski
> Committer and PMC Member of Apache Cocoon
> http://reflectingonthevicissitudes.wordpress.com/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
> For additional commands, e-mail: users-help@cocoon.apache.org
>
>
--
Bart Remmerie
AW: AW: own widget
Posted by Michel Erard <mi...@corix.ch>.
PS: I use Version 2.2 :-)
________________________________
Von: Michel Erard
Gesendet: Mi 14.11.2007 15:28
An: users@cocoon.apache.org
Betreff: AW: AW: own widget
Hi Bart,
how did you catch the label in your xsl transformation?
In forms-field-styling.xsl we have:
<!--+
| Labels for form elements.
+-->
<xsl:template match="fi:label" mode="label">
<xsl:param name="id"/>
<xsl:variable name="resolvedId">
<xsl:choose>
<xsl:when test="$id != ''"><xsl:value-of select="$id"/></xsl:when>
<xsl:otherwise><xsl:value-of select="concat(@id, ':input')"/></xsl:otherwise>
</xsl:choose>
</xsl:variable>
<label for="{$resolvedId}" title="{fi:hint}">
<xsl:apply-templates select="." mode="css"/>
<b><xsl:copy-of select="fi:label/node()"/></b>
</label>
</xsl:template>
But I think this template isn't used and the label is directly set within the AbstractWidget:
public void generateLabel(ContentHandler contentHandler) throws SAXException {
if (getCombinedState().isDisplayingValues()) {
getDefinition().generateDisplayData("label", contentHandler);
}
}
Cheers,
Mike
________________________________
Von: bart remmerie [mailto:remmerie@gmail.com]
Gesendet: Mi 14.11.2007 11:53
An: users@cocoon.apache.org
Betreff: Re: AW: own widget
Dear Michel,
I've already implemented such a feature, not by creating a new widget, but using the stylesheet-approach.
Basically, you create a new styling type "link" or "href-label" and include it in the forms styling stylesheets.
The most difficult part is to create the "href" part of your hyperlink.
For an elegant solution, you should be able to define the hyperlink outside the stylesheet.
You should be able to pass it as an argument through the form's template.
In my use case, I pass a 'fixed part', something like '/myhelppages/' + a variable part linked to the id of the record. Where the id of the record is a part of the object model, known within the form (as a hidden field) & accessible in the stylesheet.
I know this may seem complicated, and if interested I can provide the source-snippets.
Bart
2007/11/9, Michel Erard <mi...@corix.ch>:
I already tested the trunk version of forms block and the only thing that changed for uses was that all 'class' attributes are replaced by 'ref' and take a spring bean as argument. And there is a new spring config file in the forms block of course.
What do you think about a new Datatype 'object', that for example can be used to link persistent objects? Of course this feature would only make sense when you have a selection-list with a defined set of objects. Or maybe better an ObjectSelectionList?
________________________________
Von: Grzegorz Kossakowski [mailto:gkossakowski@apache.org]
Gesendet: Do 08.11.2007 18:57
An: users@cocoon.apache.org
Betreff: Re: AW: own widget
Felix Knecht pisze:
> @Grzegorz
> I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't it make more sense to use already the
> new forms block instead of the legacy one (probably it makes configuration also easier)?
Yes, Giacomo migrated forms to Spring recently but there are still two problems:
1. There was no release of Forms 1.1.0
2. There is no migration guide or any other document describing how things changed and how
everything is going to work.
The second point is especially important and I'm little bit disappointed that others making
incompatible (but wholeheartedly wanted!) changes do not write any documentation. It's really not
hard to write migration guide but I believe it really helps our users. Am I wrong?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
Bart Remmerie
AW: AW: own widget
Posted by Michel Erard <mi...@corix.ch>.
Hi Bart,
how did you catch the label in your xsl transformation?
In forms-field-styling.xsl we have:
<!--+
| Labels for form elements.
+-->
<xsl:template match="fi:label" mode="label">
<xsl:param name="id"/>
<xsl:variable name="resolvedId">
<xsl:choose>
<xsl:when test="$id != ''"><xsl:value-of select="$id"/></xsl:when>
<xsl:otherwise><xsl:value-of select="concat(@id, ':input')"/></xsl:otherwise>
</xsl:choose>
</xsl:variable>
<label for="{$resolvedId}" title="{fi:hint}">
<xsl:apply-templates select="." mode="css"/>
<b><xsl:copy-of select="fi:label/node()"/></b>
</label>
</xsl:template>
But I think this template isn't used and the label is directly set within the AbstractWidget:
public void generateLabel(ContentHandler contentHandler) throws SAXException {
if (getCombinedState().isDisplayingValues()) {
getDefinition().generateDisplayData("label", contentHandler);
}
}
Cheers,
Mike
________________________________
Von: bart remmerie [mailto:remmerie@gmail.com]
Gesendet: Mi 14.11.2007 11:53
An: users@cocoon.apache.org
Betreff: Re: AW: own widget
Dear Michel,
I've already implemented such a feature, not by creating a new widget, but using the stylesheet-approach.
Basically, you create a new styling type "link" or "href-label" and include it in the forms styling stylesheets.
The most difficult part is to create the "href" part of your hyperlink.
For an elegant solution, you should be able to define the hyperlink outside the stylesheet.
You should be able to pass it as an argument through the form's template.
In my use case, I pass a 'fixed part', something like '/myhelppages/' + a variable part linked to the id of the record. Where the id of the record is a part of the object model, known within the form (as a hidden field) & accessible in the stylesheet.
I know this may seem complicated, and if interested I can provide the source-snippets.
Bart
2007/11/9, Michel Erard <mi...@corix.ch>:
I already tested the trunk version of forms block and the only thing that changed for uses was that all 'class' attributes are replaced by 'ref' and take a spring bean as argument. And there is a new spring config file in the forms block of course.
What do you think about a new Datatype 'object', that for example can be used to link persistent objects? Of course this feature would only make sense when you have a selection-list with a defined set of objects. Or maybe better an ObjectSelectionList?
________________________________
Von: Grzegorz Kossakowski [mailto:gkossakowski@apache.org]
Gesendet: Do 08.11.2007 18:57
An: users@cocoon.apache.org
Betreff: Re: AW: own widget
Felix Knecht pisze:
> @Grzegorz
> I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't it make more sense to use already the
> new forms block instead of the legacy one (probably it makes configuration also easier)?
Yes, Giacomo migrated forms to Spring recently but there are still two problems:
1. There was no release of Forms 1.1.0
2. There is no migration guide or any other document describing how things changed and how
everything is going to work.
The second point is especially important and I'm little bit disappointed that others making
incompatible (but wholeheartedly wanted!) changes do not write any documentation. It's really not
hard to write migration guide but I believe it really helps our users. Am I wrong?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
--
Bart Remmerie
AW: AW: own widget
Posted by Michel Erard <mi...@corix.ch>.
I already tested the trunk version of forms block and the only thing that changed for uses was that all 'class' attributes are replaced by 'ref' and take a spring bean as argument. And there is a new spring config file in the forms block of course.
What do you think about a new Datatype 'object', that for example can be used to link persistent objects? Of course this feature would only make sense when you have a selection-list with a defined set of objects. Or maybe better an ObjectSelectionList?
________________________________
Von: Grzegorz Kossakowski [mailto:gkossakowski@apache.org]
Gesendet: Do 08.11.2007 18:57
An: users@cocoon.apache.org
Betreff: Re: AW: own widget
Felix Knecht pisze:
> @Grzegorz
> I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't it make more sense to use already the
> new forms block instead of the legacy one (probably it makes configuration also easier)?
Yes, Giacomo migrated forms to Spring recently but there are still two problems:
1. There was no release of Forms 1.1.0
2. There is no migration guide or any other document describing how things changed and how
everything is going to work.
The second point is especially important and I'm little bit disappointed that others making
incompatible (but wholeheartedly wanted!) changes do not write any documentation. It's really not
hard to write migration guide but I believe it really helps our users. Am I wrong?
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: AW: own widget
Posted by Felix Knecht <fe...@apache.org>.
@Grzegorz
I thought Giacomo migrated the forms block to spring (cocoon-forms-1.1.0).Wouldn't it make more sense to use already the
new forms block instead of the legacy one (probably it makes configuration also easier)?
Felix
> Michel Erard pisze:
>> Hi Grzegorz,
>>
>> yes, I think for this example your right, perhabs it's enough when I add a new xslt. But when this is not enough, how I add a widget?
>
> Let's assume you want to create widget named MyOwnWidget, then you will need to:
> 1. Implement MyOwnWidget class extending o.a.c.forms.formmodel.AbstractWidgetAbstractWidget
> 2. Implement complementary classes to the first one responsible for handling definition of widget:
> MyOwnWidgetDefinition (extending AbstractWidgetDefinition or similar) and
> MyOwnWidgetDefinitionBuilder (extending AbstractWidgetDefinitionBuilder).
> 3. Register your own widget (see [1]).
> 4. Write your own JX macros for your widget similar to standard macros (see [2]).
> 5. Write your own XSLT file for styling your own widget.
> 6. Integrate everything together. (consists of adding few imports so your macros and xsls are visible).
>
> May seem like a lot of work but in a fact most of this steps are really simple. For example, for the
> most of widgets classes implementing them are really straightforward as they inherit everything from
> abstract classes.
>
> Before you start to implement anything new I think it would be a good idea to evaluate all existing
> widgets and their varations (different styling) so you are not going to waste your time if simpler
> solution exists.
>
> I hope that helps a little.
>
> [1]
> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-forms.xconf
> [2]
> http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/generation/jx-macros.xml
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: AW: own widget
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Michel Erard pisze:
> Hi Grzegorz,
>
> yes, I think for this example your right, perhabs it's enough when I add a new xslt. But when this is not enough, how I add a widget?
Let's assume you want to create widget named MyOwnWidget, then you will need to:
1. Implement MyOwnWidget class extending o.a.c.forms.formmodel.AbstractWidgetAbstractWidget
2. Implement complementary classes to the first one responsible for handling definition of widget:
MyOwnWidgetDefinition (extending AbstractWidgetDefinition or similar) and
MyOwnWidgetDefinitionBuilder (extending AbstractWidgetDefinitionBuilder).
3. Register your own widget (see [1]).
4. Write your own JX macros for your widget similar to standard macros (see [2]).
5. Write your own XSLT file for styling your own widget.
6. Integrate everything together. (consists of adding few imports so your macros and xsls are visible).
May seem like a lot of work but in a fact most of this steps are really simple. For example, for the
most of widgets classes implementing them are really straightforward as they inherit everything from
abstract classes.
Before you start to implement anything new I think it would be a good idea to evaluate all existing
widgets and their varations (different styling) so you are not going to waste your time if simpler
solution exists.
I hope that helps a little.
[1]
http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl/src/main/resources/META-INF/cocoon/avalon/cocoon-forms.xconf
[2]
http://svn.apache.org/repos/asf/cocoon/branches/cocoon-forms-1.0.0/cocoon-forms-impl/src/main/resources/org/apache/cocoon/forms/generation/jx-macros.xml
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
AW: own widget
Posted by Michel Erard <mi...@corix.ch>.
Hi Grzegorz,
yes, I think for this example your right, perhabs it's enough when I add a new xslt. But when this is not enough, how I add a widget?
I'm using cocoon 2.2.
________________________________
Von: Grzegorz Kossakowski [mailto:gkossakowski@apache.org]
Gesendet: Do 08.11.2007 15:30
An: users@cocoon.apache.org
Betreff: Re: own widget
Michel Erard pisze:
> Hi,
>
> I'd like do implement an own widget, where the label is a link that opens a help page.
>
> Is it possible to implement a new widget, outside of the cocoon-forms block or do I have to
> extend this block? Is there a small tutorial, which classes I have to implement/overwrite?
>>From what I can see you don't need to implement a completely new widget but only implement new
styling for existing one that will show label differently, right?
If so, you will just need to create a small XSLT file and integrate it with existing Forms
infrastructure. Before I'll give you concrete hints I would like to know which version of Cocoon you
use.
--
Grzegorz Kossakowski
Committer and PMC Member of Apache Cocoon
http://reflectingonthevicissitudes.wordpress.com/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
own widget
Posted by Michel Erard <mi...@corix.ch>.
Hi,
I'd like do implement an own widget, where the label is a link that opens a help page.
Is it possible to implement a new widget, outside of the cocoon-forms block or do I have to extend this block? Is there a small tutorial, which classes I have to implement/overwrite?
Regards,
Mike
Getting Started Guide
Posted by Robin Rigby <ro...@gondolier.org.uk>.
I have follwed the Getting Started Guide as far as Using the Reloading
Classloader [1].
----
I move to getting-started-app/ and invoke
mvn eclipse:eclipse.
I get
"Cannot execute mojo: eclipse. It requires a project with an existing
pom.xml, but the build is not using one."
Am I in the wrong directory or have I missed an opportunity to create a POM?
----
Also: the current version of cocoon-maven-plugin seems to be 1.0.0-M1, not
1.0.0-M1-SNAPSHOT.
Also: throughout the Getting Started Guide, it is sometimes not clear in
which dirctory I should invoke the various mvn commands. It becomes sort of
instinctive after a while but only _after_ I have got started. :-)
Thanks
Robin
[1]
http://cocoon.zones.apache.org/dev-docs/2.2/maven-plugins/maven-plugin/1.0/1
297_1_1.html
07785 765017
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org
Re: Information about hour field type
Posted by Dev at weitling <de...@weitling.net>.
Carlos Martínez Peña wrote:
> But now, i need one more field type. I need that user can put a hour
> with cforms. It can be like data type field or using two selects, one
> for hours and another one for minuts.
>
> I don't know it is developing in the new releases or someone have
> implemented it for some similar reason.
>
> Thanks, Carlos.
Hi Carlos,
seems there's nobody working on a component like this (perhaps you could
be more precise?).
What about using an aggregatefield i.e. one select for the hourse 0-23
and one select or a restricted textfield for the minutes?
Bye,
Florian
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@cocoon.apache.org
For additional commands, e-mail: users-help@cocoon.apache.org