librelist archives

Re: [tempest] The Future of Tempest

From:

David Newman

Date:

2010-02-18 @ 18:13

Ok, I am fine with four spaces as that is also the default in my IDE.  I
turned all the auto-formatting off in my environment so it shouldn't be an
issue going forward.

I've actually started reading through the git docs and using the CLI since
that has always been the best way to learn this stuff.  Thanks for the
article it was very informative.

-Dave

On Thu, Feb 18, 2010 at 11:08 AM, Nick Fitzgerald <fitzgen@gmail.com> wrote:

> I am using 4 spaces, I come from Python land where that is the standard and
> I don't see a point to changing that.
>
> The change that I saw the most often that looked auto formatted was
> changing "function ()" to "function()". It's not a biggie, but again, its
> easier to review changes and get a feeling of what's going on when only the
> lines that are related to this feature/bug fix/etc are changed in the
> commit.
>
> You can review the changes you have made since the last commit with "git
> diff" or "fit diff <file>". You can choose which ones you want to stage for
> the next commit via "git add <file>". However, often you may want to only
> stage *part* of the changes you have made to a file (like when your editor
> had changed the whole file and you just wanted to commit the new stuff).
> This is where "git add --patch" comes in. Not sure how it works via the gui,
> but it lets you stage individual hunks from your changes, or even edit the
> diff in an editor directly. You can see the changes that you have staged by
> running "git diff --cached".
>
> You might want to checkout this article (by one of the GitHub founders, I
> believe): http://tomayko.com/writings/the-thing-about-git
>
> I have never really used the git gui but I am sure that there are ways to
> run these commands through it.
>
> Yes, I see the docs still say that it has to be a textarea to be
> automagically grabbed and turned in to a template. I will fix this soon.
>
> _Nick_
>
>
>
>
> On Thu, Feb 18, 2010 at 7:07 AM, David Newman <drogin@gmail.com> wrote:
>
>> I turned off all the auto-formatting for Javascript.  It may have actually
>> been more the fact that my editor is currently set to replace tabs as 4
>> spaces.  What should we standardize on?
>>
>> As to the implementation on L501, that is the glory of having objects just
>> be dictionaries and functions as first class citizens :)  The only thing I
>> may do there is beef it up by adding a check to see if the method exists
>> instead of invoking it right away.  That way we could at least throw a more
>> specific error message.
>>
>> -Dave
>>
>>
>> On Thu, Feb 18, 2010 at 9:14 AM, Dave Newman <drogin@gmail.com> wrote:
>>
>>> Lol, sorry if my "all" came off creepy :)
>>>
>>> I am a .net developer so I am on windows and used visual studio to edit
>>> the file. I think it probably converted the line endings or something like
>>> that.
>>>
>>> The git GUI tool supposedly converted them back to LF, so I wasn't
>>> expecting the diff to be that bad. I'm going to turn off auto formatting for
>>> js files and be more cautious before comitting.
>>>
>>> Not sure I can really convince you about the alternate way of adding
>>> templates. I was just coding and thought, "let's see if this works". I'm not
>>> particularly attached to it and at this early in the life of the framework,
>>> it makes sense to eliminate any suspected code smell. We can always add it
>>> back later.
>>>
>>> The only thing I would add is that I think the documentation still says
>>> that you have to use textareas to store you templates. After looking at the
>>> code I know that isn't true :)
>>>
>>> I will make the changes/additions you suggested. I've got firefox and use
>>> firebug all the time, I just never used fireunit.
>>>
>>> -Dave
>>>
>>>
>>>
>>> On Feb 18, 2010, at 12:43 AM, Nick Fitzgerald <fitzgen@gmail.com> wrote:
>>>
>>> Awesome!
>>>
>>> Dave, just FYI, I invited everyone who has emailed me about Tempest
>>> before to join the mailing list, but I doubt most (or even any) of them have
>>> joined yet or even will. Right now the only other person I know for a fact
>>> who is on this list is my coworker John who has used Tempest for a couple
>>> projects and has helped me out with some code when I have gotten stuck
>>> before. I'm not sure that there are enough of us to qualify as "all". :)
>>>
>>> I am browsing the code now, it looks good! I just ran the tests and all
>>> 53 are still passing which shouldn't be surprising. I like how you
>>> implemented (on line 501) for any jquery method to be used! I would not have
>>> thought of that, kudos.
>>>
>>> I have a couple of comments:
>>>
>>> First, it was kind of hard to get a feel for what your committed changes
>>> were right off the bat since you touched so much of the file. What editor do
>>> you use? Does it automatically format some things a certain way? If you look
>>> at the diff 
(<http://github.com/dotnetnomad/tempest/commit/f2aaedd38eb4d4b9697ca364c2b11d5f6d50b5f5>
>>> 
http://github.com/dotnetnomad/tempest/commit/f2aaedd38eb4d4b9697ca364c2b11d5f6d50b5f5)
>>> there is a lot of white space changes and minor code style manipulations
>>> that seem like they could be coming from an editor's auto formatting. This
>>> just makes the commit a little difficult to evaluate at a glance, which I
>>> find is somewhat important when you will be sharing your code and commits
>>> with others.
>>>
>>> Second, what was your reasoning behind creating this new way of defining
>>> templates?
>>>
>>>     $("div#my_template").tempest("my_template")
>>>
>>> I'm not sure that Tempest needs another way of defining templates. There
>>> are already two ways to do it now (via adding a tempest-template class to an
>>> element and also by $.tempest("<template name>", "<template code>")). Do you
>>> think the current ways are sub par? Why would someone define templates like
>>> this and not just have them be created automatically via tempest-template
>>> class on start up?
>>>
>>> I'm going to go ahead and merge in the other parts, and if you can
>>> convince me, this new template defining too. What would be great as a next
>>> step would be a couple unit tests (I guess we should just continue to use
>>> FireUnit for now) and a little documentation added to the README file.
>>>
>>> Basically, the only fire unit method I use is "ok" which just takes two
>>> arguments. The first is a test's result value (true means that the test
>>> passes) typically I just define a function and run it immediately like this:
>>>
>>>     fireunit.ok( (function () {
>>>         return true;
>>>     }()), "This will always pass");
>>>
>>> But fire unit is a plugin to firebug so you have to have firefox and
>>> firebug installed to use it. Grab fire unit here: <http://fireunit.org/>
>>> http://fireunit.org/ and here is some more documentation:
>>> <http://ejohn.org/blog/fireunit/>http://ejohn.org/blog/fireunit/
>>>
>>> Again, this looks great, thanks a lot!
>>>
>>> _Nick_
>>>
>>>
>>>
>>> On Wed, Feb 17, 2010 at 6:20 PM, David Newman < <drogin@gmail.com>
>>> drogin@gmail.com> wrote:
>>>
>>>> All,
>>>>
>>>> I am somewhat new to open source development, and especially new to git
>>>> so please be gentle with me if I've gone astray :)
>>>>
>>>> I figured it would be easiest if I created a github account and forked
>>>> Nick's tempest repo.  I've gone ahead and done that and my fork is located
>>>> at the following url:
>>>>
>>>> <http://github.com/dotnetnomad/tempest>
>>>> http://github.com/dotnetnomad/tempest
>>>>
>>>> I also made the initial set of changes required to further integrate
>>>> tempest with jQuery and enable some chaining.  Here is what you can do so
>>>> far:
>>>>
>>>> //equivalent to $('div#foo').html($.tempest(template, data));
>>>> $('div#foo').tempest(template, data);
>>>>
>>>> //essentially creates a new template with the given name, using the
>>>> contents of the matched tags as the template source
>>>> $('div#myTemplate').tempest('my-template-name');
>>>>
>>>> //this will replace the matched nodes with the result of rendering the
>>>> template.
>>>> //you can pass whatever jQuery method name you like as the first
>>>> argument and it should work.
>>>> $('div#placeHolder').tempest('replaceWith', template, data);
>>>>
>>>> //another example
>>>> $('body').tempest('append', template, data);
>>>>
>>>> //a simple chaining example.  Essentially populate a ul with the result
>>>> of rendering a template, then finding all the "odd" li tags and adding a
>>>> class for styling purposes
>>>> $('ul#myList').tempest('append', 'list-item-template',
>>>> listitems).find('li:odd').addClass('odd');
>>>>
>>>> Anyway, this is just a first draft.  I tested them briefly, but I've
>>>> never used FireUnit and haven't had time to learn it and make unit tests.
>>>> Therefore use at your own risk until I've had a chance to stabilize things.
>>>>
>>>> -Dave
>>>>
>>>>
>>>> On Wed, Feb 17, 2010 at 2:37 PM, Nick Fitzgerald < <fitzgen@gmail.com>
>>>> fitzgen@gmail.com> wrote:
>>>>
>>>>> Once I've done that, I am also looking at adding a further overload so
>>>>>> that other operations like append and replace can function with tempest for
>>>>>> example:
>>>>>>
>>>>>> $('div#foo').tempest('append', template, data);
>>>>>>
>>>>>> or
>>>>>>
>>>>>> $('div#foo').tempest('replaceWith', template, data);
>>>>>>
>>>>>
>>>>> This looks like a great API, I like it.
>>>>>
>>>>>
>>>>>> Also, I pretty much agree with having one form of iteration in the
>>>>>> system.  Since tempest supports creating your own tags, I think that is
>>>>>> something that is impossible to enforce, but there is a certain value in
>>>>>> having a canonical set of tags and idioms for their use.  This gives
>>>>>> everyone the same starting point and the custom tags will then be able to
>>>>>> focus on specialization rather than basic functionality.
>>>>>>
>>>>>
>>>>> Yup. My intention is that these "built in" tags will provide a good
>>>>> starting point. The idea behind the custom tag system is to let people fill
>>>>> their own niche problems, just like you have done. Of course we can't stop
>>>>> people from doing their own iteration or logic tags, but I don't think we
>>>>> would want to. If enough people are all writing the same tag extension,
>>>>> that's a hint to us.
>>>>>
>>>>> I will let the list know once I've got something working with regards
>>>>>> to the proposed modifications.  What form is it best to submit changes in?
>>>>>> Should I e-mail a patch to this list?
>>>>>>
>>>>>
>>>>> Very good question, I hadn't really thought about it. I think the best
>>>>> thing to do is just push your changes back to your github fork (or any
>>>>> publicly clone-able git repo) and then let this list know about the changes,
>>>>> and where they are accessible from. I will grab them, review the code and
>>>>> double check that tests are still passing, then merge it in to master.
>>>>>
>>>>> I just want to reiterate, if you have any questions about the code
>>>>> base, either post the question to this list as a new thread or grab me on
>>>>> gmail's chat.
>>>>>
>>>>> I'm going to start on the each/for tag tonight. Thoughts on a name and
>>>>> semantics? I think I am leaning towards "{% for person in people %}" but I
>>>>> am open to suggestions.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> _Nick_
>>>>>
>>>>>
>>>>>> -Dave
>>>>>>
>>>>>>
>>>>>> On Mon, Feb 15, 2010 at 10:43 PM, Nick Fitzgerald <<fitzgen@gmail.com>
>>>>>> fitzgen@gmail.com> wrote:
>>>>>>
>>>>>>> Tempest was designed with a slightly different philosophy from other
>>>>>>> client side templating systems. It is "purposefully stupid" to enforce the
>>>>>>> separation between the presentation and logic layers. Isn't that 
separation
>>>>>>> the *point* of using some type of templating? To alleviate the 
headache that
>>>>>>> occurs when your code is littered with strings of markup?
>>>>>>>
>>>>>>>     var elem = $("<li class='link'><a href='" + url + '">" + title +
>>>>>>> "</a></li>");
>>>>>>>
>>>>>>> But the presentation layer needs some very simple control structures;
>>>>>>> it would be useless without any logic or looping mechanisms. Right now,
>>>>>>> Tempest has the very minimum required in this regard. If 
statements with no
>>>>>>> else. Iteration via array-like data structures rather than 
template syntax.
>>>>>>>
>>>>>>> This has served pretty well so far but I think there is room for
>>>>>>> improvement. I find the lack of else statements a nuisance (the 
only reason
>>>>>>> they are missing is that I was lazy and thought I could get away 
with it). I
>>>>>>> also think that a syntax for iteration inside templates is desirable.
>>>>>>> Tempest already has the building blocks for these features and extensions,
>>>>>>> it is just a matter of bootstrapping now.
>>>>>>>
>>>>>>> David has written a custom tag[1] that is a perfect example of taking
>>>>>>> advantage of what Tempest already can do to create new and useful 
syntax in
>>>>>>> the templates.
>>>>>>>
>>>>>>> We (David and I) talked about an "each" (or "foreach" or simply
>>>>>>> "for") tag that might be used like this:
>>>>>>>
>>>>>>>     <ul>
>>>>>>>       {% each person in people %}
>>>>>>>         <li>{{ <http://person.name>person.name }}</li>
>>>>>>>       {% endeach %}
>>>>>>>     </ul>
>>>>>>>
>>>>>>> in addition to incorporating something like the "iter" tag he wrote.
>>>>>>>
>>>>>>> The more that I think about it, though, the more I am convinced that
>>>>>>> Tempest only needs one type of iteration syntax. I don't want Tempest to
>>>>>>> become a full blown mini language. Simplicity. Nothing more than needed.
>>>>>>> What do you think?
>>>>>>>
>>>>>>> I also think that the FireUnit tests (which is Firefox only) need to
>>>>>>> be converted to something more portable. The big IE bug I just had
to write
>>>>>>> a replacement "split" function for is a perfect example of why this is
>>>>>>> important.
>>>>>>>
>>>>>>> David has also expressed interest in writing an extension to Tempest
>>>>>>> so that these two forms are equivalent:
>>>>>>>
>>>>>>>     $("#foo").tempest(template, data) // New way
>>>>>>>     $("#foo").html($.tempest(template, data)) // Old way
>>>>>>>
>>>>>>> which sounds great to me. David, go ahead and grab the clone from
>>>>>>> github and let me know when you have something for me to look at.
>>>>>>>
>>>>>>> Lastly, how do you guys think the documentation is? I think it is
>>>>>>> somewhat thorough, but might be lacking an overall picture. 
Suggestions for
>>>>>>> improvement?
>>>>>>>
>>>>>>> _Nick_
>>>>>>>
>>>>>>> [1]
>>>>>>> <http://geekswithblogs.net/dotnetnomad/archive/2010/02/07/137844.aspx>
>>>>>>> http://geekswithblogs.net/dotnetnomad/archive/2010/02/07/137844.aspx
>>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>