User talk:Pawanseerwani 1/GSoC proposal

Dicussion page for Pawan Kumar D's GSoC Proposal

Test first

If you first write all the code and only then write the tests, you will not be gaining all that much value. Tests help you during development and can allow you to go faster when used correctly (by eliminating nearly all debugging time). They also force a certain decoupling into your design. If you write tests afterwards, you might find it very hard, as your code will likely not be designed in a testable way. You'll also likely not be writing tests for all the code, since after all, you already "know it works", so at that point doing a good job is simply less likely due to psychological reasons.

--Jeroen De Dauw (talk) 21:44, 9 March 2014 (UTC)

I agree on your point. But I have included 'write unit tests and testing' phase twice (Jun 16-22 & Jul 16-22) excluding the final testing phase(Aug 01-07). So all in all 3 testing phases. Do you want me to add more phases of testing? -- Pawanseerwani 1 (talk) 08:29, 11 March 2014 (UTC)

Column with 'edit' links

I had something more Excel-like in mind where all the cells of the table contain inputs right away without the 'edit' links. Any thoughts? Pros? Cons? --F.trott (talk) 23:33, 10 March 2014 (UTC)

I thought about that, but a user wouldn't edit most of the pages, instead he would edit some(say about 5-10) pages at once. Also, for small editing purposes, it would add unnecessary load on DB where most of the rows wouldn't be affected at all. So I thought of the other approach with edit column. -- Pawanseerwani 1 (talk) 08:29, 11 March 2014 (UTC)

Well, you could check for unchanged pages. And also MediaWiki already checks for unchanged pages and will not save them. Finally, you could do some JavaScript magic to not submit unchanged pages. --F.trott (talk) 15:52, 11 March 2014 (UTC)

Agreed, there won't be load on DB. But I am afraid, too many input boxes won't be user friendly. Perhaps a solution can be to display the tabular structure and on single/double click, it gets converted to an input box? -- Pawanseerwani 1 (talk) 20:19, 11 March 2014 (UTC)

Tabular Editing for Category pages

We have been discussing multiple modification of pages made by single semantic form. But a single semantic form can be used to create pages for multiple categories. And a user would want to edit pages belonging to a certain category, as he wouldn't care to think what Semantic Form it was made from. So we can give an option for edit of multiple pages belonging to a certain category. Thoughts? -- Pawanseerwani 1 (talk) 08:29, 11 March 2014 (UTC)

Ideally the list of pages would be the result of a semantic query, like given in #ask (see http://semantic-mediawiki.org/wiki/Help:Selecting_pages). I would not try to deduce which form to use from the pages. Instead just provide a parameter, just like with the #forminput, #formedt and #autoedit parser functions (see Extension:Semantic_Forms/Linking_to_forms). What about something like {{#multiformedit:form=SomeForm|targets=[[Catgory:Foo]][[SomeProperty::Bar]]}}? --F.trott (talk) 16:03, 11 March 2014 (UTC)

Hmm, as an afterthought, you could probably add a 'category' parameter (and a 'namespace' parameter while you are at it), that would 1) reduce the set of pages (i.e. work like an AND condition on the query) and 2) make it possible to automatically deduce the form. But to be honest, I see that as secondary. Usually, whoever puts the #multiedit parser function call in a wiki page knows enough about the wiki to know the form. Especially since forms usually are named after their target category. (Just learned about pinging a user from inside the wiki, and I have to try it: Yaron Koren, what do you think?) --F.trott (talk) 16:27, 11 March 2014 (UTC)

Your method is simple and clean :) -- Pawanseerwani 1 (talk) 20:19, 11 March 2014 (UTC)