[Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Julian Fitzell-2
So, wouldn't it be better to store this on the RenderContext? Or even
change CallbackRegistry to store the lastId instead of the nextId.
Seems weird adding this instance variable to the Renderer,
particularly when the answer the question really should be valid
across any renderer within the same context.

Julian

On Thu, Jan 28, 2010 at 12:05 PM,
<[hidden email]> wrote:

> Lukas Renggli uploaded a new version of Seaside-Core to project Seaside 3.0:
> http://www.squeaksource.com/Seaside30/Seaside-Core-lr.607.mcz
>
> ==================== Summary ====================
>
> Name: Seaside-Core-lr.607
> Author: lr
> Time: 28 January 2010, 9:04:43 pm
> UUID: ecc7667e-df27-4509-9f21-a08c6b875c20
> Ancestors: Seaside-Core-jok.606
>
> - removed #peekNextId, never saw any users of that
> - added #lastId, which is extremely useful for labels and also nicer for people that used #peekNextId
>
> =============== Diff against Seaside-Core-jok.606 ===============
>
> Item was changed:
>  WAObject subclass: #WARenderer
> +       instanceVariableNames: 'context lastId'
> -       instanceVariableNames: 'context'
>        classVariableNames: ''
>        poolDictionaries: ''
>        category: 'Seaside-Core-Rendering'!
>  WARenderer class
>        instanceVariableNames: 'default'!
>
>  !WARenderer commentStamp: 'jf 2/13/2009 19:57' prior: 0!
>  A Renderer provides methods for rendering data (typically HTML) onto a Document. It gets all the information needed to do its work from a RenderContext, which is passed in on initialization.
>
>  Renderer are typically controlled by a Painter.!
>
> Item was changed:
>  ----- Method: WARenderer>>nextId (in category 'public') -----
>  nextId
> +       "Answer an identifier string that is unique within this RenderContext."
> -       "Return a identifier string that is unique within this RenderContext."
>
> +       ^ lastId := 'id' , self callbacks advanceKey!
> -       ^ 'id' , self callbacks advanceKey!
>
> Item was added:
> + ----- Method: WARenderer>>lastId (in category 'public') -----
> + lastId
> +       "Answer the last identifier that was generated with #nextId."
> +
> +       ^ lastId!
>
> Item was removed:
> - ----- Method: WARenderer>>peekNextId (in category 'public') -----
> - peekNextId
> -       "Return the indentifier string that will be returned by the next call to #nextId."
> -
> -       ^ 'id' , self callbacks nextKey!
>
>
> _______________________________________________
> commits mailing list
> To unsubscribe, email [hidden email]
> http://lists.seaside.st/listinfo/commits
>
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Lukas Renggli
Yeah, I don't care where it is actually stored. Probably it should
also be separated from the callbacks.

Lukas

On 28 January 2010 23:39, Julian Fitzell <[hidden email]> wrote:

> So, wouldn't it be better to store this on the RenderContext? Or even
> change CallbackRegistry to store the lastId instead of the nextId.
> Seems weird adding this instance variable to the Renderer,
> particularly when the answer the question really should be valid
> across any renderer within the same context.
>
> Julian
>
> On Thu, Jan 28, 2010 at 12:05 PM,
> <[hidden email]> wrote:
>> Lukas Renggli uploaded a new version of Seaside-Core to project Seaside 3.0:
>> http://www.squeaksource.com/Seaside30/Seaside-Core-lr.607.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Seaside-Core-lr.607
>> Author: lr
>> Time: 28 January 2010, 9:04:43 pm
>> UUID: ecc7667e-df27-4509-9f21-a08c6b875c20
>> Ancestors: Seaside-Core-jok.606
>>
>> - removed #peekNextId, never saw any users of that
>> - added #lastId, which is extremely useful for labels and also nicer for people that used #peekNextId
>>
>> =============== Diff against Seaside-Core-jok.606 ===============
>>
>> Item was changed:
>>  WAObject subclass: #WARenderer
>> +       instanceVariableNames: 'context lastId'
>> -       instanceVariableNames: 'context'
>>        classVariableNames: ''
>>        poolDictionaries: ''
>>        category: 'Seaside-Core-Rendering'!
>>  WARenderer class
>>        instanceVariableNames: 'default'!
>>
>>  !WARenderer commentStamp: 'jf 2/13/2009 19:57' prior: 0!
>>  A Renderer provides methods for rendering data (typically HTML) onto a Document. It gets all the information needed to do its work from a RenderContext, which is passed in on initialization.
>>
>>  Renderer are typically controlled by a Painter.!
>>
>> Item was changed:
>>  ----- Method: WARenderer>>nextId (in category 'public') -----
>>  nextId
>> +       "Answer an identifier string that is unique within this RenderContext."
>> -       "Return a identifier string that is unique within this RenderContext."
>>
>> +       ^ lastId := 'id' , self callbacks advanceKey!
>> -       ^ 'id' , self callbacks advanceKey!
>>
>> Item was added:
>> + ----- Method: WARenderer>>lastId (in category 'public') -----
>> + lastId
>> +       "Answer the last identifier that was generated with #nextId."
>> +
>> +       ^ lastId!
>>
>> Item was removed:
>> - ----- Method: WARenderer>>peekNextId (in category 'public') -----
>> - peekNextId
>> -       "Return the indentifier string that will be returned by the next call to #nextId."
>> -
>> -       ^ 'id' , self callbacks nextKey!
>>
>>
>> _______________________________________________
>> commits mailing list
>> To unsubscribe, email [hidden email]
>> http://lists.seaside.st/listinfo/commits
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>



--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

[Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Julian Fitzell-2
In reply to this post by Julian Fitzell-2
Oh, I just noticed that the id is not the same as the callback key,
which makes things less clear-cut. Since "ids" are only known by the
renderer, it's less weird than I was thinking to store the last id
there. I still wonder whether getting the last callback key and
prepending 'id' to it again wouldn't be better but maybe it's less
"accurate" in the abstract sense.

Julian

On Thu, Jan 28, 2010 at 2:39 PM, Julian Fitzell <[hidden email]> wrote:

> So, wouldn't it be better to store this on the RenderContext? Or even
> change CallbackRegistry to store the lastId instead of the nextId.
> Seems weird adding this instance variable to the Renderer,
> particularly when the answer the question really should be valid
> across any renderer within the same context.
>
> Julian
>
> On Thu, Jan 28, 2010 at 12:05 PM,
> <[hidden email]> wrote:
>> Lukas Renggli uploaded a new version of Seaside-Core to project Seaside 3.0:
>> http://www.squeaksource.com/Seaside30/Seaside-Core-lr.607.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Seaside-Core-lr.607
>> Author: lr
>> Time: 28 January 2010, 9:04:43 pm
>> UUID: ecc7667e-df27-4509-9f21-a08c6b875c20
>> Ancestors: Seaside-Core-jok.606
>>
>> - removed #peekNextId, never saw any users of that
>> - added #lastId, which is extremely useful for labels and also nicer for people that used #peekNextId
>>
>> =============== Diff against Seaside-Core-jok.606 ===============
>>
>> Item was changed:
>>  WAObject subclass: #WARenderer
>> +       instanceVariableNames: 'context lastId'
>> -       instanceVariableNames: 'context'
>>        classVariableNames: ''
>>        poolDictionaries: ''
>>        category: 'Seaside-Core-Rendering'!
>>  WARenderer class
>>        instanceVariableNames: 'default'!
>>
>>  !WARenderer commentStamp: 'jf 2/13/2009 19:57' prior: 0!
>>  A Renderer provides methods for rendering data (typically HTML) onto a Document. It gets all the information needed to do its work from a RenderContext, which is passed in on initialization.
>>
>>  Renderer are typically controlled by a Painter.!
>>
>> Item was changed:
>>  ----- Method: WARenderer>>nextId (in category 'public') -----
>>  nextId
>> +       "Answer an identifier string that is unique within this RenderContext."
>> -       "Return a identifier string that is unique within this RenderContext."
>>
>> +       ^ lastId := 'id' , self callbacks advanceKey!
>> -       ^ 'id' , self callbacks advanceKey!
>>
>> Item was added:
>> + ----- Method: WARenderer>>lastId (in category 'public') -----
>> + lastId
>> +       "Answer the last identifier that was generated with #nextId."
>> +
>> +       ^ lastId!
>>
>> Item was removed:
>> - ----- Method: WARenderer>>peekNextId (in category 'public') -----
>> - peekNextId
>> -       "Return the indentifier string that will be returned by the next call to #nextId."
>> -
>> -       ^ 'id' , self callbacks nextKey!
>>
>>
>> _______________________________________________
>> commits mailing list
>> To unsubscribe, email [hidden email]
>> http://lists.seaside.st/listinfo/commits
>>
>
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Julian Fitzell-2
In reply to this post by Lukas Renggli
Oh, you mean it shouldn't even use the callback registry to get the
unique part. No, I guess you're right... it really shouldn't. :) Ok,
well then I suggest storing a counter on the RenderContext and having
it provide the IDs. Renderer can delegate the protocol through. What
do you think?

Julian

On Thu, Jan 28, 2010 at 2:42 PM, Lukas Renggli <[hidden email]> wrote:

> Yeah, I don't care where it is actually stored. Probably it should
> also be separated from the callbacks.
>
> Lukas
>
> On 28 January 2010 23:39, Julian Fitzell <[hidden email]> wrote:
>> So, wouldn't it be better to store this on the RenderContext? Or even
>> change CallbackRegistry to store the lastId instead of the nextId.
>> Seems weird adding this instance variable to the Renderer,
>> particularly when the answer the question really should be valid
>> across any renderer within the same context.
>>
>> Julian
>>
>> On Thu, Jan 28, 2010 at 12:05 PM,
>> <[hidden email]> wrote:
>>> Lukas Renggli uploaded a new version of Seaside-Core to project Seaside 3.0:
>>> http://www.squeaksource.com/Seaside30/Seaside-Core-lr.607.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Seaside-Core-lr.607
>>> Author: lr
>>> Time: 28 January 2010, 9:04:43 pm
>>> UUID: ecc7667e-df27-4509-9f21-a08c6b875c20
>>> Ancestors: Seaside-Core-jok.606
>>>
>>> - removed #peekNextId, never saw any users of that
>>> - added #lastId, which is extremely useful for labels and also nicer for people that used #peekNextId
>>>
>>> =============== Diff against Seaside-Core-jok.606 ===============
>>>
>>> Item was changed:
>>>  WAObject subclass: #WARenderer
>>> +       instanceVariableNames: 'context lastId'
>>> -       instanceVariableNames: 'context'
>>>        classVariableNames: ''
>>>        poolDictionaries: ''
>>>        category: 'Seaside-Core-Rendering'!
>>>  WARenderer class
>>>        instanceVariableNames: 'default'!
>>>
>>>  !WARenderer commentStamp: 'jf 2/13/2009 19:57' prior: 0!
>>>  A Renderer provides methods for rendering data (typically HTML) onto a Document. It gets all the information needed to do its work from a RenderContext, which is passed in on initialization.
>>>
>>>  Renderer are typically controlled by a Painter.!
>>>
>>> Item was changed:
>>>  ----- Method: WARenderer>>nextId (in category 'public') -----
>>>  nextId
>>> +       "Answer an identifier string that is unique within this RenderContext."
>>> -       "Return a identifier string that is unique within this RenderContext."
>>>
>>> +       ^ lastId := 'id' , self callbacks advanceKey!
>>> -       ^ 'id' , self callbacks advanceKey!
>>>
>>> Item was added:
>>> + ----- Method: WARenderer>>lastId (in category 'public') -----
>>> + lastId
>>> +       "Answer the last identifier that was generated with #nextId."
>>> +
>>> +       ^ lastId!
>>>
>>> Item was removed:
>>> - ----- Method: WARenderer>>peekNextId (in category 'public') -----
>>> - peekNextId
>>> -       "Return the indentifier string that will be returned by the next call to #nextId."
>>> -
>>> -       ^ 'id' , self callbacks nextKey!
>>>
>>>
>>> _______________________________________________
>>> commits mailing list
>>> To unsubscribe, email [hidden email]
>>> http://lists.seaside.st/listinfo/commits
>>>
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
>
>
>
> --
> Lukas Renggli
> http://www.lukas-renggli.ch
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
Reply | Threaded
Open this post in threaded view
|

Re: [Seaside-dev] Re: [Seaside Commits] Seaside 3.0: Seaside-Core-lr.607.mcz

Lukas Renggli
> Oh, you mean it shouldn't even use the callback registry to get the
> unique part. No, I guess you're right... it really shouldn't. :) Ok,
> well then I suggest storing a counter on the RenderContext and having
> it provide the IDs. Renderer can delegate the protocol through. What
> do you think?

Yes exactly. If it was separated from the callbacks we also don't need
to store it extra, because we would know the previous id. In any case,
I just want to be able to write things like this without temps:

    html label
        for: html nextId;
        with: 'Suspect'.
    html textInput
        callback: [ :v ... ];    " that shouldn't mess with the IDs "
        id: html lastId

or

    html checkbox
        ensureId;
        callback: [ ... ];     " that shouldn't mess with the IDs "
    html label
        for: html lastId;
        with: 'suspicious'

Lukas




>
> Julian
>
> On Thu, Jan 28, 2010 at 2:42 PM, Lukas Renggli <[hidden email]> wrote:
>> Yeah, I don't care where it is actually stored. Probably it should
>> also be separated from the callbacks.
>>
>> Lukas
>>
>> On 28 January 2010 23:39, Julian Fitzell <[hidden email]> wrote:
>>> So, wouldn't it be better to store this on the RenderContext? Or even
>>> change CallbackRegistry to store the lastId instead of the nextId.
>>> Seems weird adding this instance variable to the Renderer,
>>> particularly when the answer the question really should be valid
>>> across any renderer within the same context.
>>>
>>> Julian
>>>
>>> On Thu, Jan 28, 2010 at 12:05 PM,
>>> <[hidden email]> wrote:
>>>> Lukas Renggli uploaded a new version of Seaside-Core to project Seaside 3.0:
>>>> http://www.squeaksource.com/Seaside30/Seaside-Core-lr.607.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Seaside-Core-lr.607
>>>> Author: lr
>>>> Time: 28 January 2010, 9:04:43 pm
>>>> UUID: ecc7667e-df27-4509-9f21-a08c6b875c20
>>>> Ancestors: Seaside-Core-jok.606
>>>>
>>>> - removed #peekNextId, never saw any users of that
>>>> - added #lastId, which is extremely useful for labels and also nicer for people that used #peekNextId
>>>>
>>>> =============== Diff against Seaside-Core-jok.606 ===============
>>>>
>>>> Item was changed:
>>>>  WAObject subclass: #WARenderer
>>>> +       instanceVariableNames: 'context lastId'
>>>> -       instanceVariableNames: 'context'
>>>>        classVariableNames: ''
>>>>        poolDictionaries: ''
>>>>        category: 'Seaside-Core-Rendering'!
>>>>  WARenderer class
>>>>        instanceVariableNames: 'default'!
>>>>
>>>>  !WARenderer commentStamp: 'jf 2/13/2009 19:57' prior: 0!
>>>>  A Renderer provides methods for rendering data (typically HTML) onto a Document. It gets all the information needed to do its work from a RenderContext, which is passed in on initialization.
>>>>
>>>>  Renderer are typically controlled by a Painter.!
>>>>
>>>> Item was changed:
>>>>  ----- Method: WARenderer>>nextId (in category 'public') -----
>>>>  nextId
>>>> +       "Answer an identifier string that is unique within this RenderContext."
>>>> -       "Return a identifier string that is unique within this RenderContext."
>>>>
>>>> +       ^ lastId := 'id' , self callbacks advanceKey!
>>>> -       ^ 'id' , self callbacks advanceKey!
>>>>
>>>> Item was added:
>>>> + ----- Method: WARenderer>>lastId (in category 'public') -----
>>>> + lastId
>>>> +       "Answer the last identifier that was generated with #nextId."
>>>> +
>>>> +       ^ lastId!
>>>>
>>>> Item was removed:
>>>> - ----- Method: WARenderer>>peekNextId (in category 'public') -----
>>>> - peekNextId
>>>> -       "Return the indentifier string that will be returned by the next call to #nextId."
>>>> -
>>>> -       ^ 'id' , self callbacks nextKey!
>>>>
>>>>
>>>> _______________________________________________
>>>> commits mailing list
>>>> To unsubscribe, email [hidden email]
>>>> http://lists.seaside.st/listinfo/commits
>>>>
>>> _______________________________________________
>>> seaside-dev mailing list
>>> [hidden email]
>>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>>
>>
>>
>>
>> --
>> Lukas Renggli
>> http://www.lukas-renggli.ch
>> _______________________________________________
>> seaside-dev mailing list
>> [hidden email]
>> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>>
> _______________________________________________
> seaside-dev mailing list
> [hidden email]
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>



--
Lukas Renggli
http://www.lukas-renggli.ch
_______________________________________________
seaside-dev mailing list
[hidden email]
http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev