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 |
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 |
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 |
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 |
> 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 |
Free forum by Nabble | Edit this page |