So, take a look at the news modules. With just some modifications, you will
have your testimonials capability.
Hi Florent
Thanks, I think changes on news module can work for me. This works
almost in the same way as per my requirements.... :-)
Florent André wrote:
On Thu, 13 Aug 2009 13:36:37 +0530, Anish <[email protected]>
wrote:
is there a special reason why you want to store all testimonials in a
single page? My first idea would be to store them in separate
documents because this makes the repository much more flexible (e.g.,
you have separate meta data and workflow instances for the
testimonials).
IMO the only reason for storing multiple content items in a single
document is the limited scalability of the sitetree, but this should
only be noticeable when there are several 10.000 or 100.000 documents.
The collection resource type is a convenient way to handle collections
of documents. Maybe it could also be useful for the testimonials.
-- Andreas
Thanks Andreas,
There is not any special reason of going for a single XML file.
I got your point of storing separate documents, I agree it would be more
convenient to handle version control, repository and other CMS related
tasks if we go for separate XMLs.
So, take a look at the news modules. With just some modifications, you will
have your testimonials capability.
++
Anish wrote:
Sorry, I don't understand your question.
hummm, I don't think so. If we have this xml structure :
<testimonials>
<testimonial>
<title>blabla</title>
<content>......</content>
</testimonial>
<testimonial>
<title>blabla2</title>
<content>......2</content>
</testimonial>
</testimonials>
When we edit with one-form editor and want to add a testimonial,
just
add
<testi></testi> bloc.
Hi Florent
I wanted to ask that how to add
<testi></testi> bloc.
While making it editable using one form editor. I'm not much clear
about this.
Please suggest.
Florent André wrote:
Sorry, I don't understand your question.
++
On Wed, 12 Aug 2009 21:09:39 +0530, Anish <[email protected]>
<mailto:[email protected]>
wrote:
hummm, I don't think so. If we have this xml structure :
<testimonials>
<testimonial>
<title>blabla</title>
<content>......</content>
</testimonial>
<testimonial>
<title>blabla2</title>
<content>......2</content>
</testimonial>
</testimonials>
When we edit with one-form editor and want to add a testimonial, just
add
<testi></testi> bloc.
Thanks for the response Florent, but how will it append the same XML.
I'm bit confused about this.
Please suggest.
Florent André wrote:
On Wed, 12 Aug 2009 14:34:04 +0530, Anish <[email protected]>
<mailto:[email protected]>
wrote:
IMO steps are :
1 - define your xml testimonial's structure
2 - build a rng
3 - add module
4 - enable a one form editor
5 - add modif/suppress on each testi
6 - enable form (with 1 field for each information)
7 - add some cooool javascript
8 - be appy and drink some wine ! :)
Hi Florent
Thanks for the guidance, if I follow these steps, the module created
will work in a way that it will create different XMLs for each of
the
testimonial page like other index_{language}.xml files. But I wanted
to
place all the testimonials in a single XML file.
Please correct me if I'm wrong.
hummm, I don't think so. If we have this xml structure :
<testimonials>
<testimonial>
<title>blabla</title>
<content>......</content>
</testimonial>
<testimonial>
<title>blabla2</title>
<content>......2</content>
</testimonial>
</testimonials>
When we edit with one-form editor and want to add a testimonial, just
add
<testi></testi> bloc.
Another solution could be inspired by news module :
- a testimonials component-instance that is a collection
- sub-testimonial component-instant that is a testimonial xml
structure
In this case each testimonial is an xml file (in the testimonials
folder),
but when you open testimonials the collection aggregate for you each
single
xml in one.
IMO this second solution have to be if content of each testimonial
could
be
long.
HTH and be careful that is just some dev ideas, I don't implement
something
like that (first no, second idea yes in a some way) for now.
I'm interesting in this subject, so keep in touch.
++
Florent André wrote:
Hey ! What do you think about the name "FillByForm" for our "module
experience" ?
++
On Tue, 11 Aug 2009 19:14:38 +0200, Florent André
<[email protected]>
<mailto:[email protected]> wrote:
Hi Vik
For me my requirements are :
- add and modify a vocabulary I have an xml like that :
<voc:team>
<voc:longname>Chealsea FC</voc:longname>
<voc:shortname>Chelsea</voc:shortname>
<voc:synonyms>
<voc:synonym>Fulham stadium</voc:synonym>
</voc:synonyms>
<voc:team>
- add some pre-defined properties (attributes values) to a link :
<a href="...." evaluation="good|middle|bad">link description</a>.
I
would
like that my user have just to select "evaluation" value in a
drop-down
list.
For sure, we have to do one for see where it can be generalized,
but
IMO,
the hardest thing to made generic is the component-instance
declaration
[1].
After that, the form to fill information would be hard to
generalize,
but
if we use cform it will just be an xml to adapt to our
requirements...
I'm in the candy world ? :) (http://candyworld.free.fr/)
Have a good day
[1}
<component-instance name="person" logger="lenya.resourcetypes"
class="org.apache.lenya.cms.publication.ResourceTypeImpl">
<schema
namespace="http://relaxng.org/ns/structure/0.9";
<http://relaxng.org/ns/structure/0.9>
uri="fallback://lenya/modules/person/resources/schemas/foaf.rng"
/>
<!-- Default time cache time in seconds for this resource type
-->
<expires seconds="3600" />
<sample
name="Basic FOAF sample"
mime-type="application/rdf+xml"
uri="fallback://lenya/modules/person/samples/foaf.xml"
/>
<format name="xhtml" uri="cocoon://modules/person/xhtml.xml"/>
<format name="xhtml-include"
uri="cocoon://modules/person/xhtml-include.xml"/>
<format name="icon" uri="cocoon://modules/person/icon"/>
</component-instance>
On Tue, 11 Aug 2009 15:14:52 +0100, Vik Tara <[email protected]>
<mailto:[email protected]>
wrote:
Hi Florent,
I also would like to do something like that. Not on
testimonial,
but
for
end-user (CMS user) it's the same think I want.
What's your requirement? I wonder if it can be made generic as
you
say.
Also can any of the lenya dev's comment if we are following the
correct
approach?
Or should we be defining a usecase?
Regards
Vik
Florent André wrote:
Hi Anish,
I also would like to do something like that. Not on testimonial,
but
for
end-user (CMS user) it's the same think I want.
A very good first step will be :
http://lenya.apache.org/docu20/tutorials/newResourceType/newResourceTypePart1.html
IMO steps are :
1 - define your xml testimonial's structure
2 - build a rng
3 - add module
4 - enable a one form editor
5 - add modif/suppress on each testi
6 - enable form (with 1 field for each information)
7 - add some cooool javascript
8 - be appy and drink some wine ! :)
for 1 to 4 I'm not really affraid... We have doc ! But for 5 to
7...
I you are OK to put your code on a public svn [1], I will like
to
code
with
you [2]
++
[1] http://svn.4sengines.eu for example ? ;)
[2] said this last phrase with a babe voice :)
On Mon, 10 Aug 2009 18:32:11 +0530, Anish
<[email protected]> <mailto:[email protected]>
wrote:
Hi All
I want to create a module "Testimonials" (it will handle all
the
operations related to the testimonials like writing, reading,
editing,
deleting etc.)
My idea of doing this is as follows:
*1. User will create a new testimonial using CMS menu.*
When user will click on "New Testimonial" option a new form
will
be
there which will contain fields related to the new testimonial
(name,
info, testimonial-text, picture etc). Then user will fill
and
save
the testimonial.
*2. User will be able to update, delete testimonials using
CMS.*
On the testimonial page in authoring area, there will be
edit/delete
option for each testimonial.
*3. All the testimonials will be placed in a single XML file.*
*4. In the live area there will be a testimonials page which
will
show
all the testimonials as read only.*
*/*User here refers to CMS user./*
I don't have much idea about implementing/writing lenya
usecases.
Please Suggest
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
<mailto:[email protected]>
For additional commands, e-mail: [email protected]
<mailto:[email protected]>
--
Anish Sneh
Software Engineer
Techblue Softwares Pvt. Ltd.
www.technologyblueprint.co.uk <http://www.technologyblueprint.co.uk>
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
--
Anish Sneh
Software Engineer
Techblue Softwares Pvt. Ltd.
www.technologyblueprint.co.uk
