You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Grzegorz Kossakowski <gr...@tuffmail.com> on 2007/03/23 17:53:54 UTC
Help with review
Hello,
I've put the proposal I'm willing to apply to Google here:
http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
I'd would be grateful for any review, comments and even edits fixing
language mistakes. I'm sorry it took so long, I had some personal
affairs to settle.
Thanks for any help.
--
Grzegorz Kossakowski
Re: Help with review
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> according to http://www.timezoneconverter.com/cgi-bin/tzc.tzc it is
> the same:
>
> 05:00:00 p.m. Monday March 26, 2007 in US/Pacific converts to
> 12:00:00 Midnight Tuesday March 27, 2007 in UTC
> ^^^^^^^^
> Daylight Saving Time is in effect on this date/time in US/Pacific
> Daylight Saving Time is not in effect on this date/time in UTC
Ah, thanks. I was confused because I'm used to 24-hour format. Now,
being appeased can do some Cocoon coding... :)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Help with review
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz napisał(a):
>>>
>>> Done. I didn't mention for every period in timeline that I'll discuss
>>> something. It's quite obvious that I'll do in first phase and while
>>> actual coding. I hope that proposal looks like you would like it to
>>> look. If not, tell me what's still wrong and I will try fix it. We have
>>> still one, long day for it. :)
>> wait till tommorrow evening to give Daniel a chance to comment, but +1
>> for the proposal from me.
>>
>
> I'm glad to see that you like it and want to thank you again for you
> effort. I wonder if we can wait...
> On Google's site:
> http://code.google.com/support/bin/answer.py?answer=60325&topic=10729 I see:
> March 26: Student application deadline; applications must be received by
> 5:00 PM Pacific time (12:00 AM UTC March 27, 2007)
>
> And I'm bit confused. Am I right that there is some mistake with this
> dates? March 26 5:00 PM Pacific time is not the same time as 12:00 AM
> UTC March 27, 2007, yes?
according to http://www.timezoneconverter.com/cgi-bin/tzc.tzc it is the same:
05:00:00 p.m. Monday March 26, 2007 in US/Pacific converts to
12:00:00 Midnight Tuesday March 27, 2007 in UTC
^^^^^^^^
Daylight Saving Time is in effect on this date/time in US/Pacific
Daylight Saving Time is not in effect on this date/time in UTC
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Help with review
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz napisał(a):
>>
>> Done. I didn't mention for every period in timeline that I'll discuss
>> something. It's quite obvious that I'll do in first phase and while
>> actual coding. I hope that proposal looks like you would like it to
>> look. If not, tell me what's still wrong and I will try fix it. We have
>> still one, long day for it. :)
>
> wait till tommorrow evening to give Daniel a chance to comment, but +1
> for the proposal from me.
>
I'm glad to see that you like it and want to thank you again for you
effort. I wonder if we can wait...
On Google's site:
http://code.google.com/support/bin/answer.py?answer=60325&topic=10729 I see:
March 26: Student application deadline; applications must be received by
5:00 PM Pacific time (12:00 AM UTC March 27, 2007)
And I'm bit confused. Am I right that there is some mistake with this
dates? March 26 5:00 PM Pacific time is not the same time as 12:00 AM
UTC March 27, 2007, yes?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Help with review
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>> Reinhard Poetz napisał(a):
>>>
>>> Hmm, I think that I do not understand exact meaning of 'deliverables'.
>> i'd define it as "measureable" goals. How does your mentor, who isn't
>> only mentor but also assessor, know that you reached your goals or
>> not. If we don't define deliverables properly, there would be much
>> more room for interpretation.
>>
>> I'm perfectly fine if you say "I will work on problem X and provide a
>> solution at May, 31th. Then there are 7 days for discussions. Starting
>> with June, 8th, I will start with the implementation.".
>
> Done. I didn't mention for every period in timeline that I'll discuss
> something. It's quite obvious that I'll do in first phase and while
> actual coding. I hope that proposal looks like you would like it to
> look. If not, tell me what's still wrong and I will try fix it. We have
> still one, long day for it. :)
wait till tommorrow evening to give Daniel a chance to comment, but +1 for the
proposal from me.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Help with review
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>> Reinhard Poetz napisał(a):
>>
>> Hmm, I think that I do not understand exact meaning of 'deliverables'.
>
> i'd define it as "measureable" goals. How does your mentor, who isn't
> only mentor but also assessor, know that you reached your goals or
> not. If we don't define deliverables properly, there would be much
> more room for interpretation.
>
> I'm perfectly fine if you say "I will work on problem X and provide a
> solution at May, 31th. Then there are 7 days for discussions. Starting
> with June, 8th, I will start with the implementation.".
Done. I didn't mention for every period in timeline that I'll discuss
something. It's quite obvious that I'll do in first phase and while
actual coding. I hope that proposal looks like you would like it to
look. If not, tell me what's still wrong and I will try fix it. We have
still one, long day for it. :)
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Help with review
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Reinhard Poetz napisał(a):
>> Grzegorz Kossakowski wrote:
>>> Hello,
>>>
>>> I've put the proposal I'm willing to apply to Google here:
>>> http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
>>>
>>> I'd would be grateful for any review, comments and even edits fixing
>>> language mistakes. I'm sorry it took so long, I had some personal
>>> affairs to settle.
>>>
>>> Thanks for any help.
>> I take this as your 'deliverables', right?
>>
>> 1. revise EL handling implemented in Cocoon's template block and find
>> out if
>> improvements are needed
>> 2. get rid of Avalon dependencies in EL and OM handling code
>> 3. provide consistent, complete object model for expressions
>> everywhere they are
>> used
>> 4. implement converter concept and provide basic converters'
>> implementations
>> 5. refactor at least portion of Cocoon samples so they use new ELs
>> implementation
>> 6. document new architecture, create migration guides and promote the
>> use of new
>> implementation across the community
>
> Hmm, I think that I do not understand exact meaning of 'deliverables'.
i'd define it as "measureable" goals. How does your mentor, who isn't only
mentor but also assessor, know that you reached your goals or not. If we don't
define deliverables properly, there would be much more room for interpretation.
I'm perfectly fine if you say "I will work on problem X and provide a solution
at May, 31th. Then there are 7 days for discussions. Starting with June, 8th, I
will start with the implementation.".
> In abstract I should provide overview on my main goals right? What
> should be putted in 'deliverables' section? More detailed,
> project-specific info on what kind of contributions I plan to add?
> Something like:
> * new module cocoon-expression-api
> * ELs and OM API (already exists but must be moved from template block)
> * converters API
> * new module cocoon-expression-impl
> * implementation for expression langauges for JS, JXPath, JEXL (most
> code already exist but needs clean up), possibly XReporter would be
> implemented if time permits
> * implementation of automatic, context-aware Object Model creation
> * default converters, basically the same as in
> org.apache.cocoon.forms.datatype.convertor package
> * refactored samples
> * cocoon-ajax-sample
> * cocoon-forms-sample
> * cocoon-core-additional-sample
> * possibly new module cocoon-expression-sample with stuff focused only
> on ELs
> * documentation in Daisy
> * design documents
> * tutorials on explaining how to create own EL or converter
> implementation and how to extend OM
> * migration guide
> * evangelism and fuzz on mailing lists
>
> My impression was that I do not have to provide every small detail and
> address all doubts.
you don't have to and you can't because you will learn and find out things that
you don't know today. Also the opinion of your mentor and the feedback from the
community will influence your project.
If so, I would like to make use of this right when
> it comes to converter concept. This is one is little bit fuzzy now and I
> would have to ask Daniel more questions about it. Can we leave
> converters scope little unspecified?
>
>> Some comments:
>>
>> In general: Could you please also add some timeline when you want to
>> finish what? See the project proposals of previos GSoC students to
>> find out what I mean.
>>
>> In particular:
>>
>> 1. When do you think will you be finished with it? Make it a milestone in
>> your project timeline.
>> 2. ok
>> 3. see 1.
>> 4. What basic converters do you want to implement?
>> 5. Which samples do you want to improve?
>> 6. ok (as long as you do it in Daisy ;-)
>>
>> Thanks for your proposal. I really like that you will provide weekly
>> reports which will make it easy for others to follow your work.
>>
>
> Ok, I'll add the timeline.
ok, forget my comment 4 and 5 and leave it open for now. Only add a paragraph to
the timeline about when you will let us know what converters and samples you
want to implement.
This and adding a timeline and a deliverables section should be all that needs
to be done IMO.
> One more issue: as most students in most
> countries, I'm going to have exam session in mid of June. It means that
> on the beginning of GSoC I'll not able to devote myself fully, I'd say
> that my activity will be narrowed only to discussion and research. Is it
> a serious obstacle?
no, just take it into account when you propose a timeline.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Help with review
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Reinhard Poetz napisał(a):
> Grzegorz Kossakowski wrote:
>> Hello,
>>
>> I've put the proposal I'm willing to apply to Google here:
>> http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
>>
>> I'd would be grateful for any review, comments and even edits fixing
>> language mistakes. I'm sorry it took so long, I had some personal
>> affairs to settle.
>>
>> Thanks for any help.
>
> I take this as your 'deliverables', right?
>
> 1. revise EL handling implemented in Cocoon's template block and find
> out if
> improvements are needed
> 2. get rid of Avalon dependencies in EL and OM handling code
> 3. provide consistent, complete object model for expressions
> everywhere they are
> used
> 4. implement converter concept and provide basic converters'
> implementations
> 5. refactor at least portion of Cocoon samples so they use new ELs
> implementation
> 6. document new architecture, create migration guides and promote the
> use of new
> implementation across the community
Hmm, I think that I do not understand exact meaning of 'deliverables'.
In abstract I should provide overview on my main goals right? What
should be putted in 'deliverables' section? More detailed,
project-specific info on what kind of contributions I plan to add?
Something like:
* new module cocoon-expression-api
* ELs and OM API (already exists but must be moved from template block)
* converters API
* new module cocoon-expression-impl
* implementation for expression langauges for JS, JXPath, JEXL (most
code already exist but needs clean up), possibly XReporter would be
implemented if time permits
* implementation of automatic, context-aware Object Model creation
* default converters, basically the same as in
org.apache.cocoon.forms.datatype.convertor package
* refactored samples
* cocoon-ajax-sample
* cocoon-forms-sample
* cocoon-core-additional-sample
* possibly new module cocoon-expression-sample with stuff focused only
on ELs
* documentation in Daisy
* design documents
* tutorials on explaining how to create own EL or converter
implementation and how to extend OM
* migration guide
* evangelism and fuzz on mailing lists
My impression was that I do not have to provide every small detail and
address all doubts. If so, I would like to make use of this right when
it comes to converter concept. This is one is little bit fuzzy now and I
would have to ask Daniel more questions about it. Can we leave
converters scope little unspecified?
>
> Some comments:
>
> In general: Could you please also add some timeline when you want to
> finish what? See the project proposals of previos GSoC students to
> find out what I mean.
>
> In particular:
>
> 1. When do you think will you be finished with it? Make it a milestone in
> your project timeline.
> 2. ok
> 3. see 1.
> 4. What basic converters do you want to implement?
> 5. Which samples do you want to improve?
> 6. ok (as long as you do it in Daisy ;-)
>
> Thanks for your proposal. I really like that you will provide weekly
> reports which will make it easy for others to follow your work.
>
Ok, I'll add the timeline. One more issue: as most students in most
countries, I'm going to have exam session in mid of June. It means that
on the beginning of GSoC I'll not able to devote myself fully, I'd say
that my activity will be narrowed only to discussion and research. Is it
a serious obstacle?
--
Grzegorz Kossakowski
http://reflectingonthevicissitudes.wordpress.com/
Re: Help with review
Posted by Reinhard Poetz <re...@apache.org>.
Grzegorz Kossakowski wrote:
> Hello,
>
> I've put the proposal I'm willing to apply to Google here:
> http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
>
> I'd would be grateful for any review, comments and even edits fixing
> language mistakes. I'm sorry it took so long, I had some personal
> affairs to settle.
>
> Thanks for any help.
I take this as your 'deliverables', right?
1. revise EL handling implemented in Cocoon's template block and find out if
improvements are needed
2. get rid of Avalon dependencies in EL and OM handling code
3. provide consistent, complete object model for expressions everywhere they are
used
4. implement converter concept and provide basic converters' implementations
5. refactor at least portion of Cocoon samples so they use new ELs
implementation
6. document new architecture, create migration guides and promote the use of new
implementation across the community
Some comments:
In general: Could you please also add some timeline when you want to finish
what? See the project proposals of previos GSoC students to find out what I mean.
In particular:
1. When do you think will you be finished with it? Make it a milestone in
your project timeline.
2. ok
3. see 1.
4. What basic converters do you want to implement?
5. Which samples do you want to improve?
6. ok (as long as you do it in Daisy ;-)
Thanks for your proposal. I really like that you will provide weekly reports
which will make it easy for others to follow your work.
--
Reinhard Pötz Independent Consultant, Trainer & (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
--------------------------------------------------------------------
Re: Help with review
Posted by Grzegorz Kossakowski <gk...@apache.org>.
Daniel Fagerstrom napisał(a):
> Grzegorz Kossakowski skrev:
>
> The proposal looks good, so I propose that you submit it.
>
> I just got home from a conference and have to get up early tomorrow so I
> don't have the time to do a detailed review.
>
> In you description of converters you maybe should mention that they make
> localized templates and forms much easier to write. One of the points
> with converters is that they can be locale dependent.
>
> For the scope of your converter work it could as you and Reinhard
> discussed be a little bit clearer. But as the scope of the rest of the
> project is clear enough it doesn't matter that much. It is more
> important to make sure that you submit it in time than making it perfect.
>
I corrected some language mistakes and submitted my application to GSoC.
I hope it will be accepted. :)
Regarding converters: I see need for them but the idea is little fuzzy
for me now and that's why I wasn't able to be precise enough. But let's
wait for GSoC period with asking questions. There is enough time planned
for dispelling doubts in time line.
--
Grzegorz Kossakowski
Re: Help with review
Posted by Daniel Fagerstrom <da...@nada.kth.se>.
Grzegorz Kossakowski skrev:
> Hello,
>
> I've put the proposal I'm willing to apply to Google here:
> http://wiki.apache.org/general/SummerOfCode2007/cocoon-expression
>
> I'd would be grateful for any review, comments and even edits fixing
> language mistakes. I'm sorry it took so long, I had some personal
> affairs to settle.
>
> Thanks for any help.
The proposal looks good, so I propose that you submit it.
I just got home from a conference and have to get up early tomorrow so I
don't have the time to do a detailed review.
In you description of converters you maybe should mention that they make
localized templates and forms much easier to write. One of the points
with converters is that they can be locale dependent.
For the scope of your converter work it could as you and Reinhard
discussed be a little bit clearer. But as the scope of the rest of the
project is clear enough it doesn't matter that much. It is more
important to make sure that you submit it in time than making it perfect.
/Daniel