| *** Joins: kirillka (~Miranda@global01.vester.ru) | 00:18 | |
| *** Quits: kirillka (~Miranda@global01.vester.ru) (Ping timeout: 260 seconds) | 00:41 | |
| *** Joins: Orac|away (~jb_buldog@082-146-096-175.dyn.adsl.xs4all.be) | 00:42 | |
| *** Joins: kirillka (~Miranda@global01.vester.ru) | 01:03 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 260 seconds) | 01:13 | |
| *** Quits: Orac|away (~jb_buldog@082-146-096-175.dyn.adsl.xs4all.be) (Ping timeout: 260 seconds) | 01:36 | |
| *** Quits: kirillka (~Miranda@global01.vester.ru) (Quit: kirillka) | 01:37 | |
| *** Quits: siebrand (~beis@sm.xs4all.nl) () | 01:44 | |
| *** Joins: kirillka (~Miranda@global01.vester.ru) | 02:31 | |
| *** Quits: kirillka (~Miranda@global01.vester.ru) (Read error: Connection reset by peer) | 02:36 | |
| *** Joins: kirillka (~Miranda@global01.vester.ru) | 02:37 | |
| *** Joins: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) | 03:52 | |
| *** Joins: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) | 04:01 | |
| *** Quits: kirillka (~Miranda@global01.vester.ru) (Quit: kirillka) | 05:07 | |
| *** Joins: necropsy (~necropsy@175.145.0.30) | 05:09 | |
| necropsy | Hi everyone. Will there be a feature that would make it possible to assign an issue to multiple developers? | 05:10 |
|---|---|---|
| *** Quits: necropsy (~necropsy@175.145.0.30) (Ping timeout: 265 seconds) | 06:06 | |
| *** Joins: PennStater- (Aaron@c-98-236-4-139.hsd1.pa.comcast.net) | 06:16 | |
| *** Quits: PennStater (Aaron@unaffiliated/pennstater) (Ping timeout: 264 seconds) | 06:19 | |
| *** Quits: PennStater- (Aaron@c-98-236-4-139.hsd1.pa.comcast.net) (Changing host) | 06:27 | |
| *** Joins: PennStater- (Aaron@unaffiliated/pennstater) | 06:27 | |
| *** PennStater- is now known as PennStater | 06:28 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 08:16 | |
| *** Quits: dhx_m (~anonymous@c122-107-185-177.eburwd5.vic.optusnet.com.au) (Remote host closed the connection) | 08:44 | |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Read error: Operation timed out) | 09:16 | |
| *** Joins: daryn (~daryn@rrcs-76-79-4-2.west.biz.rr.com) | 10:00 | |
| *** Parts: Rixie (~Rixie@0x4dd7390e.adsl.cybercity.dk) | 10:06 | |
| *** Joins: dhx_m (~anonymous@c122-107-185-177.eburwd5.vic.optusnet.com.au) | 10:27 | |
| *** Quits: rolfkleef (~rolf@82-204-30-154.dsl.bbeyond.nl) (Ping timeout: 258 seconds) | 11:24 | |
| *** Joins: moto-moi (~hylke@cara.xs4all.nl) | 11:59 | |
| *** Joins: mantisbt_66669 (c83b8855@gateway/web/freenode/ip.200.59.136.85) | 12:35 | |
| *** Quits: mantisbt_66669 (c83b8855@gateway/web/freenode/ip.200.59.136.85) (Client Quit) | 12:36 | |
| *** Joins: siebrand (~beis@sm.xs4all.nl) | 12:45 | |
| nuclear_eclipse | daryn: around? | 13:29 |
| daryn | nuclear_eclipse am now | 13:41 |
| nuclear_eclipse | hi daryn | 13:46 |
| daryn | hello | 13:46 |
| nuclear_eclipse | had an initial look at filters | 13:46 |
| daryn | ok | 13:46 |
| daryn | fire away | 13:46 |
| nuclear_eclipse | haven't been able to test it out yet though, just been browsing the github history | 13:46 |
| daryn | so...initial thoughts? | 13:48 |
| nuclear_eclipse | first, it seems to me that the filter class hierarchy is rather complex, and relatedly, it seemingly gets split up between almost too many files... | 13:48 |
| nuclear_eclipse | relatedly, it seems like there's a lot of extra logic that gets put into each end class, and maybe it's me, but it seems like there should be a simpler solution... =\ | 13:49 |
| nuclear_eclipse | but before I get too into it, mind if I ask what your design decisions were, and how that might affect what I'm seeing? | 13:50 |
| daryn | well... | 13:50 |
| daryn | # 1 i wanted to not stray to terribly far from what you started with MantisFilter | 13:51 |
| daryn | the number of classes actually turned out to be quite a few more than i first anticipated | 13:52 |
| daryn | i really don't like putting multiple classes into one file but it could be done | 13:53 |
| daryn | i initially had a switch for the variations of field type but then i was winding up with switches everywhere | 13:53 |
| daryn | I wouldn't be opposed at all to merging some classes where it makes sense...for example multi-int, multi-string | 13:55 |
| nuclear_eclipse | another concern is that perhaps too much of the logic for handling/rendering filters is in kept in the same class hierarchy, like MantisFilterSort and MantisFilterSticky which seem to be separate classes that don't really act like the other filters | 13:56 |
| daryn | could be. they were that way because they are stored that way in the filter string and still need fields on the form | 13:58 |
| nuclear_eclipse | I guess I feel like the MantisFilter* classes should be reduced to only describing the datasets, and use some sort of external system to aggregate, query, and render that data set | 13:58 |
| nuclear_eclipse | I'm also not really sure what the point of MantisFilterCookieVersion is for... | 13:59 |
| daryn | i don't know about that one. i can see that is kind of the direction you were going...it seems even more complex to me. | 13:59 |
| daryn | Filter | 13:59 |
| daryn | CookieVersion probably can go away. again it was just another field in the filter string and i was trying to maintain the existing strings without a bunch of weird code to figure out what should be a class and what shouldn't...it just helps me to break everything down first and then work on restructuring in a more coherent way | 14:00 |
| nuclear_eclipse | the reason I suggest that is because I want the process of creating new filters to be as simple and straightforward as possible; if the current MantisFilter* classes are an example, then the complexity of writing new filters seems to have increased at least by a factor of ten | 14:01 |
| daryn | i'd disagree actually | 14:01 |
| daryn | we do have to add a couple of missing pieces that i'm working on but essentially to add a filter one just needs a small class and a configuration to use it | 14:03 |
| nuclear_eclipse | again, maybe this is just the result of not having fully comprehended what's going on | 14:03 |
| daryn | and everything needed is in that one class | 14:03 |
| daryn | except possibly a different template if the field output is different than what is available | 14:03 |
| daryn | well, i agree that there are certainly some changes needed in the class structure and some of the classes should be perhaps be removed in favor of a different process... | 14:06 |
| nuclear_eclipse | also, starting to get nit picky, but I'd personally prefer something like $filter->addWhereClause( ...) rather than $filter->addQueryElement( 'where_clauses', ... ) | 14:09 |
| daryn | hehe...i already have that in my branch | 14:09 |
| nuclear_eclipse | first method IMO would be less error-prone, ntm more succinct | 14:10 |
| nuclear_eclipse | lol | 14:10 |
| daryn | the way i work is probably a nightmare to most people...i usually just have to start coding and stuff gets rewritten a lot before i get what i want. | 14:11 |
| nuclear_eclipse | I sometimes do that to explore the problem space with a small prototype, but I usually try to sit back and design what I want, and then simplify my design as much as possible, before I actually start putting real code in place | 14:13 |
| nuclear_eclipse | even if the designing is just a 20-30 minute meditation, I find it helps to focus some time on looking for ways to simplify the design before moving forward | 14:14 |
| nuclear_eclipse | it's unfortunate, but most of the time, simplifying code that's already in place is near impossible | 14:14 |
| daryn | yes...especially filters | 14:14 |
| nuclear_eclipse | so doing as much simplification up front as possible is definitely worth the reduced headache later on | 14:15 |
| daryn | i could see that there was alot of duplication but it took me several runs through the code to even figure out what was really going on. | 14:15 |
| daryn | that's when i started trying to break it into little bits and got where i am now. | 14:15 |
| nuclear_eclipse | tbh though, if it simplifies your design at all, I'd personally be willing to just completely ignore any existing filters or conversion of those filters to the new format | 14:15 |
| daryn | hm...now you tell me | 14:16 |
| daryn | :) | 14:16 |
| nuclear_eclipse | ;) | 14:16 |
| nuclear_eclipse | I was never really prompted to fully think about replacing the existing filters until looking through what you have | 14:16 |
| nuclear_eclipse | up to now, I tried my best to stay away from filters altogether, and only touch the bare minimum if I had to do anything at all | 14:17 |
| daryn | i think that's how everyone felt about it but stuff just kept getting tacked on | 14:18 |
| nuclear_eclipse | the only reason I even wrote MantisFilter and MantisColumn in the first place was because I needed a way to add those features to the plugins I was writing | 14:18 |
| daryn | adding a new filter or modifying an old one required checking in 10 (arbitrary exaggeration) different places | 14:18 |
| daryn | copy and paste a chunk of code here and there | 14:19 |
| nuclear_eclipse | ten places is probably an understatement | 14:19 |
| nuclear_eclipse | if you didn't find 10+ places to change, you were probably missing something ... =\ | 14:19 |
| daryn | i found that the system was completely reloading the query 3 or 4 times for one page load | 14:19 |
| nuclear_eclipse | there were two disjoint code paths just for dynamic versus static filter pages | 14:20 |
| daryn | yeah and they were never both updated | 14:20 |
| daryn | we'd add a field in one and forget the other, fix a bug in one and forget the other... | 14:20 |
| nuclear_eclipse | yup | 14:21 |
| nuclear_eclipse | another random thought -- I wonder if we could combine filter changes with an overhaul of view/update pages... | 14:21 |
| daryn | So anyway, I do have some additional ideas that i think will move us closer together. It will take me a bit to get them ready and i'm heading on vacation in a couple of weeks so no promises on delivery | 14:21 |
| daryn | the bug pages? | 14:22 |
| nuclear_eclipse | yeah | 14:22 |
| daryn | i'm listening | 14:22 |
| nuclear_eclipse | ie, have a central MantisField class that defines all the fields usable on a report/view/edit page for an issue, and then define MantisFilter objects for how to search for that data | 14:23 |
| nuclear_eclipse | it's probably not easy though | 14:24 |
| daryn | hm...sounds like you, me and dhx_m or at least on the same wavelength.... | 14:24 |
| nuclear_eclipse | having a set of generalized MantisField classes would at least allow us to properly "template" the report/view/edit pages as a set of fields that each define their own "cell" of data | 14:25 |
| nuclear_eclipse | we could potentially even combine that along with filtering, rather than keeping them separate | 14:26 |
| nuclear_eclipse | ie, you'd more or less never need to filter on something that's not a specific field, and if you do, the existing MantisFilter for plugins could still fill that role... | 14:27 |
| nuclear_eclipse | /shrug | 14:27 |
| nuclear_eclipse | there's so much I would like to be able to do, and so little time or energy... | 14:27 |
| nuclear_eclipse | it was nice getting paid to improve Mantis | 14:27 |
| nuclear_eclipse | too bad that had to end | 14:28 |
| daryn | how do you mean you'd never need to filter on something not a specific field? | 14:28 |
| nuclear_eclipse | well, I can't think of a single filter in mantis that isn't a direct counterpart to a field on the report/view/edit page... | 14:29 |
| daryn | except that meta fields, sticky, show, changed, | 14:30 |
| nuclear_eclipse | sticky is still a field of each issue, last changed is a field of each issue... | 14:30 |
| daryn | true | 14:31 |
| daryn | changed field though is not last changed...it's related to last changed but not the same | 14:31 |
| nuclear_eclipse | ? | 14:31 |
| nuclear_eclipse | I'm just thinking of some unified datatype: | 14:32 |
| daryn | yeah | 14:32 |
| daryn | i need a better picture i guess | 14:32 |
| nuclear_eclipse | class MantisField { func view(bug_id); func edit(bug_id); ... func filter(...); func query(...); ... } | 14:33 |
| nuclear_eclipse | and if the field declares its type, and mantis can interpret that correctly, it completely separates the display output from the data itself | 14:33 |
| nuclear_eclipse | the only oddity is certain field types that don't fit "standard" types, like my Product Matrix plugin | 14:34 |
| nuclear_eclipse | but you could potentially just make that another "standard" type where the plugin does all of its own output formatting, or something... | 14:35 |
| nuclear_eclipse | ie, mantis gives it a cell, and it generates its own markup as needed | 14:35 |
| daryn | i'm not really following how this would work... you are passing bug_id to func view... what is the context of that? what would it do, how would it be used? | 14:37 |
| nuclear_eclipse | ie, the bug view page would have a list of fields that it needs to display, and for each field, tells it what bug_id is being viewed, and the field object returns that bug's data for the given field, and then the view page renders that in some appropriate cell based on the type of data for that field | 14:39 |
| daryn | where is the data for the bug? | 14:40 |
| nuclear_eclipse | the view page doesn't need to know anything about the bug itself, nor do the field objects need to know anything about how the bug API is caching the bug data in the backend so it's not constantly hitting the database | 14:40 |
| nuclear_eclipse | ie, it's a complete separation of concerns | 14:41 |
| daryn | right | 14:41 |
| nuclear_eclipse | but that sort of thing will allow custom fields and plugin fields to treated identically to each other, because either way, the bug view page isn't responsible for gathering any of the data, it only knows what fields it needs to display, and how to render specific data types | 14:42 |
| daryn | right | 14:42 |
| nuclear_eclipse | and btw, changed filter is just a filter for last_updated, and just happens to display a bit different depending on current time in relation to the last_updated value | 14:44 |
| daryn | yeah,yeah | 14:44 |
| daryn | :) | 14:44 |
| daryn | it doesn't change the result, just the display of the result | 14:45 |
| nuclear_eclipse | and btw, I'm not just being harsh on you, I made this same sort of argument about externalizing the rendering from the data type when I was working on game projects in school | 14:45 |
| daryn | i'm cool. just trying to process a different way of thinking about it. | 14:46 |
| nuclear_eclipse | OOP says that each object should know how to render itself, but a) that splits rendering algorithms into N+1 places, where N is the number of data types you have, and b) starts mixing unrelated code segments into a single data structure | 14:47 |
| nuclear_eclipse | so wherever possible, I try to separate out rendering logic from data definitions | 14:47 |
| nuclear_eclipse | "rendering logic" | 14:48 |
| nuclear_eclipse | it's not always in regards to rendering, but it's a similar concept for other topics | 14:48 |
| daryn | well...in some sense that's why i have the MantisBugFilter object...it's a collection of filters and handles the things that are related between all the filters but the filters handle their own differences | 14:49 |
| nuclear_eclipse | yeah, and I think that's a good start, and like I said, I could just have an incorrect mental model of what's going on | 14:50 |
| daryn | each filter knows everything it needs to know about itself and if it needs to know about another filter it can get that...ie status/hide status | 14:50 |
| nuclear_eclipse | it just seemed to me that there was still a lot of verbose duplication of logic between all the MantisFilter* classes | 14:51 |
| daryn | there may be some duplication but there shouldn't be a lot. | 14:51 |
| daryn | if there is i'm in the process of removing it | 14:51 |
| nuclear_eclipse | ugh, I want status/hide status to die a quick but extremely painful death | 14:51 |
| daryn | :) | 14:51 |
| daryn | it has a place | 14:51 |
| nuclear_eclipse | gimme a damn multiselect box anyday | 14:52 |
| daryn | we're forcing our filters to advanced view | 14:52 |
| daryn | so that's what you get | 14:52 |
| daryn | k. well i have a lot to think about now and a lot of other work to get done before i can get into filters again so...thanks for your input. was helpful | 14:53 |
| nuclear_eclipse | you're welcome | 14:53 |
| daryn | i'll try to have an update in ... a week or two | 14:54 |
| nuclear_eclipse | ok, and like I said about templates, I'm willing to compromise on what I'm looking for just because it's *implemented* and *better than what's already there* | 14:54 |
| nuclear_eclipse | so please don't get discouraged :) | 14:55 |
| daryn | :) | 14:55 |
| daryn | i'm facing a pressured deadline to get our mantis upgraded so it's going to be a bit before i can get back to templates but they are still in my mind | 14:56 |
| nuclear_eclipse | all I care about is making you think about what I've mentioned, and make *some decision*, just as long as it's actually a decision with a reason behind it, rather than "that's just how it happened" | 14:56 |
| daryn | :) | 14:57 |
| nuclear_eclipse | if you can give me an actual reason of why I'm being stupid about something, I'll be happy that you were able to let me realize I was being stupid :P | 14:57 |
| nuclear_eclipse | anywho, get back to work slacker, stop wasting your time on that stupid IRC crap | 14:58 |
| * daryn ... nose to the grindstone | 14:59 | |
| * daryn nope...teatime | 14:59 | |
| *** Joins: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) | 15:00 | |
| nuclear_eclipse | phew, we finished chatting before paulr crashed the party | 15:01 |
| nuclear_eclipse | oh hi Paul! | 15:01 |
| * daryn runs to hide | 15:01 | |
| paulr | i'm hopefully catching up with dhx tomorrow | 15:09 |
| paulr | need to diff java | 15:10 |
| *** Joins: fanno (~Morten@90.184.93.233) | 15:20 | |
| *** Joins: rolfkleef (~rolf@urtica.xs4all.nl) | 16:11 | |
| *** Quits: mellen (~thansen@x1-6-00-22-02-00-0c-40.k253.webspeed.dk) (Ping timeout: 252 seconds) | 17:05 | |
| *** Joins: mellen (~thansen@x1-6-00-22-02-00-0c-40.k253.webspeed.dk) | 17:07 | |
| *** Quits: moto-moi (~hylke@cara.xs4all.nl) (Quit: Ex-Chat) | 17:33 | |
| *** Joins: micahg (~micah@ubuntu/member/micahg) | 17:36 | |
| *** Quits: daryn (~daryn@rrcs-76-79-4-2.west.biz.rr.com) (Ping timeout: 264 seconds) | 17:56 | |
| *** Joins: daryn (~daryn@rrcs-76-79-11-122.west.biz.rr.com) | 18:13 | |
| *** Quits: daryn (~daryn@rrcs-76-79-11-122.west.biz.rr.com) (Quit: Ex-Chat) | 18:24 | |
| *** Quits: rolfkleef (~rolf@urtica.xs4all.nl) (Ping timeout: 240 seconds) | 18:58 | |
| *** Quits: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) (Remote host closed the connection) | 19:59 | |
| *** Joins: scribe9343423 (~scribe934@static.96.23.63.178.clients.your-server.de) | 20:00 | |
| *** Quits: paulr (~paul@cpc1-enfi9-0-0-cust389.hari.cable.virginmedia.com) () | 20:18 | |
| *** Quits: fanno (~Morten@90.184.93.233) (Quit: Leaving.) | 20:23 | |
| dhx_m | nuclear_eclipse: I was thinking of a Field class that is extremely basic at it's core | 20:36 |
| dhx_m | nuclear_eclipse: then you have "interfaces" that print the field in HTML, plaintext, XML, etc | 20:37 |
| dhx_m | that way you can use the Field class without bringing in 1000's of lines of HTML parsing code, etc | 20:37 |
| dhx_m | (ie. keep coupling low) | 20:37 |
| *** Quits: micahg (~micah@ubuntu/member/micahg) (Ping timeout: 276 seconds) | 21:12 | |
Generated by irclog2html.py 2.9.2 by Marius Gedminas - find it at mg.pov.lt!