| *** menesis has quit IRC | 01:39 | |
| *** alga has joined #schooltool | 01:40 | |
| *** alga has quit IRC | 02:59 | |
| *** yvl has joined #schooltool | 07:54 | |
| *** th1a has quit IRC | 08:00 | |
| *** replaceafill has quit IRC | 10:01 | |
| *** menesis has joined #schooltool | 11:10 | |
| *** ignas has joined #schooltool | 11:23 | |
| aelkner_ | yvl, ayt? | 12:13 |
|---|---|---|
| yvl | aelkner_, here! | 12:41 |
| yvl | was away to lunch | 12:42 |
| aelkner_ | i just read your response, and i have a couple of comments | 12:42 |
| aelkner_ | first, i think you are confusing the word reference and request | 12:43 |
| aelkner_ | Manage->Reports brings up a app context view that list all reports in the system | 12:43 |
| aelkner_ | you can't request reports there | 12:43 |
| aelkner_ | the context is app | 12:43 |
| yvl | I understand that | 12:43 |
| aelkner_ | One adapter to define the link in Manage->Reports. Another to define the link in a reference view. | 12:44 |
| aelkner_ | that sonds like you are saying they are two different things when they are in fact on in the same | 12:44 |
| yvl | my point was - that they are not | 12:45 |
| aelkner_ | so Manage->Reprots is not the reference view | 12:46 |
| aelkner_ | what is it then, the request view | 12:46 |
| aelkner_ | that would be impossible | 12:46 |
| yvl | the system should not care | 12:46 |
| aelkner_ | let's not get overly abstract | 12:46 |
| aelkner_ | i'm not a system, i'm a person | 12:46 |
| yvl | ok | 12:46 |
| yvl | ... | 12:47 |
| aelkner_ | and i need to define terms in a way that i can know that i'm talking about the same thing as someone else | 12:47 |
| aelkner_ | so | 12:47 |
| aelkner_ | Manage->Reports brings up a reference view | 12:47 |
| yvl | ok | 12:47 |
| aelkner_ | the links in the table will not request any reports, they can't | 12:47 |
| aelkner_ | they will take the user to a context view, depending on the type of report | 12:48 |
| aelkner_ | there the user can find the obnject | 12:48 |
| yvl | and what do you call the other views? | 12:48 |
| aelkner_ | once a schooltool or term or section or person is the actual context | 12:48 |
| yvl | lemme find an example... | 12:48 |
| aelkner_ | there will be a Reprots action link | 12:49 |
| aelkner_ | that brings p the report request view | 12:49 |
| yvl | ah, ok then | 12:49 |
| aelkner_ | listing links for requesting the various reports for that context | 12:49 |
| yvl | my point was, that for the link collection mechanism | 12:50 |
| yvl | they are same views | 12:50 |
| yvl | sources of links | 12:50 |
| yvl | to something that you can get reports from | 12:50 |
| aelkner_ | no, the links are different in the two different cases | 12:51 |
| yvl | but mechanism is the same | 12:51 |
| yvl | the links are indeed different | 12:51 |
| aelkner_ | ok, for each report, i need the following | 12:52 |
| aelkner_ | 1) a title to display in the reference view | 12:52 |
| aelkner_ | 2) a description for the reference view | 12:52 |
| aelkner_ | 3) a context type (human readable) for the reference view | 12:52 |
| aelkner_ | 4) a url that is the same for all of the above three in the particlar row of the table | 12:53 |
| aelkner_ | then, additionally, for the request view, i need: | 12:54 |
| aelkner_ | 1) the same title for the link text | 12:54 |
| aelkner_ | 2) the link url for requesting the report | 12:54 |
| aelkner_ | couldn't one adapter provide 1-4, then 2 | 12:55 |
| aelkner_ | and the two different views would be interested in different things | 12:55 |
| aelkner_ | so, for the reference view, the adapter lookup would get all adapters | 12:56 |
| aelkner_ | regardless of what they adapt, to get all reports in the system | 12:56 |
| aelkner_ | but the report request view would only get the adatpers for the given context | 12:56 |
| aelkner_ | does that make sense? | 12:56 |
| yvl | [thinking] | 12:58 |
| aelkner_ | btw, perhaps 1) from section two could be a differerent lin k text | 12:59 |
| aelkner_ | like, "Request Failure Report" in the request view | 13:00 |
| aelkner_ | but "Failure Report" in the reference view | 13:00 |
| aelkner_ | or just "Failures" as report is redundant | 13:01 |
| yvl | so, you want 1-4 for one context, and 5-6 for other context | 13:01 |
| yvl | all mashed up in one adapter on the first context? | 13:01 |
| aelkner_ | the app context is not a relevant context | 13:01 |
| aelkner_ | so i'm not sure what you mean | 13:01 |
| yvl | [a] | 13:02 |
| yvl | [thinking again ;) ] | 13:02 |
| yvl | how do you plan to deal with multiple school years? | 13:04 |
| aelkner_ | i don't | 13:04 |
| yvl | ok | 13:05 |
| yvl | well then | 13:05 |
| aelkner_ | how do you mean? | 13:05 |
| yvl | failures by term in 3 years | 13:05 |
| yvl | what links should show app in Manage->Reports? | 13:05 |
| aelkner_ | show app? | 13:05 |
| yvl | "show in Manage Reports" | 13:06 |
| yvl | sorry :) | 13:06 |
| aelkner_ | think Mnage->persons | 13:06 |
| yvl | "show up in Manage Reports" | 13:06 |
| aelkner_ | it's a table view | 13:06 |
| aelkner_ | multiple columns | 13:06 |
| yvl | no | 13:06 |
| yvl | I am asking | 13:06 |
| yvl | Manage->Reports | 13:06 |
| yvl | absences by day | 13:07 |
| yvl | or any other per-year report | 13:07 |
| aelkner_ | every report in the system, period | 13:07 |
| yvl | how do you access reports of previous years? | 13:07 |
| yvl | define every report in the system | 13:07 |
| aelkner_ | ok, you're assuming something that is clouding your view here | 13:08 |
| yvl | frankly, I don't think that my view is clouded at all | 13:08 |
| aelkner_ | Manage->Reports has as it's link: | 13:08 |
| yvl | in this case | 13:08 |
| aelkner_ | localhost:7080/reports.html | 13:08 |
| aelkner_ | note the app context | 13:08 |
| aelkner_ | that view list every report in the system, all context types | 13:09 |
| aelkner_ | reports for schoolyear, term, section, person | 13:09 |
| aelkner_ | all of them | 13:09 |
| aelkner_ | one row per report | 13:09 |
| aelkner_ | three columns, title, description, context type | 13:09 |
| aelkner_ | all three cells have the same url | 13:09 |
| yvl | ok | 13:09 |
| yvl | define again every report in the system | 13:10 |
| yvl | is it every type of report in the system | 13:10 |
| yvl | or every generatable report in the system | 13:10 |
| aelkner_ | ? | 13:10 |
| yvl | look | 13:10 |
| yvl | say person | 13:10 |
| yvl | has a gradebook | 13:10 |
| yvl | and say, he can print his report | 13:11 |
| yvl | a simple student | 13:11 |
| yvl | wants to print a report of his grades | 13:11 |
| yvl | now | 13:11 |
| yvl | "report grades for 2011" -> a report type | 13:11 |
| aelkner_ | no, no | 13:11 |
| aelkner_ | way off | 13:11 |
| aelkner_ | look, ther is only one gradebook report | 13:11 |
| aelkner_ | you have to navigate to the gradebook itself to request it | 13:12 |
| aelkner_ | but in the reference view | 13:12 |
| aelkner_ | it wold be list once as a gradebook report | 13:12 |
| aelkner_ | climing on it would take the user to the gradebook | 13:12 |
| yvl | which one? | 13:12 |
| yvl | 2010, 2011? | 13:12 |
| yvl | wich gradebook? | 13:12 |
| aelkner_ | you hit the Gradebook tab, whta do you get? | 13:12 |
| yvl | so, no historical data | 13:12 |
| yvl | I see. | 13:13 |
| aelkner_ | yeah, i never said anything of the sort | 13:13 |
| yvl | ok | 13:13 |
| yvl | so, you want to simply list 10 or so links | 13:13 |
| aelkner_ | tom wants the user to be able to see what kind of reports exist, plain and simple | 13:13 |
| aelkner_ | 10 or so rows | 13:13 |
| aelkner_ | three links per row | 13:13 |
| yvl | seriously | 13:13 |
| yvl | hard-code them | 13:13 |
| yvl | no utilities, no nothing | 13:14 |
| yvl | at best | 13:14 |
| yvl | use viewlets | 13:14 |
| aelkner_ | missing the point again | 13:14 |
| aelkner_ | the idea is to have a view that knows what reports exist without knwoing they exist | 13:14 |
| aelkner_ | it knows becuase they are registered | 13:14 |
| yvl | first | 13:14 |
| yvl | seriously | 13:15 |
| yvl | read what viewlets are | 13:15 |
| yvl | second | 13:15 |
| yvl | I stand by with what I suggested | 13:15 |
| yvl | in the email | 13:15 |
| yvl | the thing you think is the same - it's not the same | 13:15 |
| yvl | and yes | 13:15 |
| yvl | there are two contexts | 13:15 |
| yvl | and yes, one of them is app | 13:15 |
| aelkner_ | i know what viewlets are | 13:16 |
| yvl | ah, ok good :) | 13:16 |
| aelkner_ | there is the viewlet manager | 13:16 |
| yvl | no, I believe you | 13:16 |
| aelkner_ | and the viewlets that are registered against them | 13:16 |
| yvl | just didn't seem so from the context | 13:16 |
| yvl | my mistake | 13:17 |
| yvl | apologies | 13:17 |
| aelkner_ | that's ok | 13:17 |
| aelkner_ | i just don't see why i would want to create a viewlet manager to make a table view | 13:17 |
| aelkner_ | it's over-engineering | 13:18 |
| aelkner_ | table views are complex enough | 13:18 |
| aelkner_ | so i can write one using the person container view as an example | 13:18 |
| aelkner_ | and the view would need to look up all registered reports in order to create the data source | 13:18 |
| yvl | well | 13:19 |
| yvl | it'll probably be best to leave the details to you | 13:19 |
| yvl | just don't do if interface.providedBy | 13:19 |
| yvl | anywhere | 13:19 |
| aelkner_ | why not? | 13:19 |
| yvl | because I said so | 13:20 |
| aelkner_ | is zope deprecated thgat feature? | 13:20 |
| yvl | you need explicit permission from me :) | 13:20 |
| yvl | for the code to get merged :) | 13:20 |
| aelkner_ | why provide the methid if it isn't to be used? | 13:20 |
| * yvl takes the dictator-something batton | 13:20 | |
| yvl | look | 13:20 |
| yvl | in the case you described | 13:20 |
| yvl | it's a clear design flaw | 13:21 |
| yvl | don't do that | 13:21 |
| yvl | there are exceptions | 13:21 |
| yvl | where hacks are appropriate | 13:21 |
| yvl | and that's why it is there | 13:21 |
| yvl | also - legacy | 13:21 |
| yvl | I don't like hacks in core | 13:21 |
| yvl | makes things icky to maintain | 13:22 |
| yvl | then again | 13:23 |
| yvl | the release is near | 13:23 |
| yvl | so whatever | 13:23 |
| aelkner_ | yeah, well i am trying to get something done in that short time | 13:23 |
| aelkner_ | but i think i see your general desire to use adapters rather than pvovidedBy | 13:24 |
| aelkner_ | and where i see added complexity with tons of adapters, you see tranquility | 13:24 |
| aelkner_ | god help me if i don't know why something is working because zeop doesn't tell you why an adapter lookup fails | 13:25 |
| aelkner_ | it just fails | 13:25 |
| aelkner_ | at least when i write code that tests things myself, i can pdb trace and see what happened | 13:25 |
| aelkner_ | zope adapters are very hostile when they don't work | 13:25 |
| aelkner_ | example, AppInit | 13:26 |
| aelkner_ | if the code fails, nothing happens | 13:26 |
| aelkner_ | you don't get an exception or something that tells you what went wrong | 13:26 |
| aelkner_ | just nothing | 13:27 |
| aelkner_ | because exceptions while adapting mean you can't adapt | 13:27 |
| aelkner_ | it's very hostile | 13:27 |
| aelkner_ | so while i recognize that we need adpaters | 13:28 |
| aelkner_ | i don't rush out to create ten thousand of them | 13:28 |
| aelkner_ | but i know that zope is like a religion for you guys a POV | 13:28 |
| aelkner_ | anyway, if you are going to reject code that has providedBy, i'll just have to write the stupid adapters | 13:29 |
| aelkner_ | btw, i don't mean to sound hostile myself, just expressing my own opinion, for what it's worth | 13:32 |
| aelkner_ | yvl, i hope i haven't driven you away, throwing your hands up | 13:33 |
| aelkner_ | this report reference view is complicated with the table and filtering and all | 13:34 |
| aelkner_ | i was hoping that we could agree on what to do there | 13:35 |
| yvl | I went to smoke ;) | 13:35 |
| yvl | and went out a bit ;) | 13:35 |
| aelkner_ | and i could use you help with the table view | 13:35 |
| yvl | by the way, AppInit silent failures are on my ever-so-inifinite TODO list | 13:36 |
| yvl | it's a bug | 13:36 |
| yvl | thing is | 13:36 |
| yvl | that when you write ifs | 13:36 |
| yvl | you are mimicking the way the adapters work | 13:36 |
| aelkner_ | yeah, but with no magic | 13:37 |
| aelkner_ | i can see it | 13:37 |
| yvl | I understand | 13:37 |
| yvl | I saw same reaction in good ol' C++ days | 13:37 |
| yvl | you know | 13:39 |
| yvl | you could write the first implementation whatever way you feel comfortable with | 13:40 |
| yvl | I can bake some magic later on | 13:40 |
| yvl | so that people could extend that logic | 13:40 |
| yvl | but still | 13:41 |
| yvl | it's not a religion thing | 13:41 |
| aelkner_ | yeah, well i admit that was harsh | 13:41 |
| yvl | frankly, I find it hard to explain via IRC | 13:42 |
| aelkner_ | another thing for the sprint | 13:42 |
| aelkner_ | tom jokes that i say that about everything | 13:42 |
| yvl | ;) | 13:42 |
| aelkner_ | as a practical matter, how would you suggest i write the table view | 13:42 |
| aelkner_ | what example table view would have a formatter that is similar to what i need to write? | 13:43 |
| yvl | [looking for it] | 13:45 |
| aelkner_ | i mean, table formatters always need containers, right? | 13:45 |
| aelkner_ | perhaps i should just write the view using my own page template and forget the complexities of TAbleFormatter | 13:46 |
| aelkner_ | i could have the text box and the drop-down for filtering, and have a <table> in my template | 13:47 |
| yvl | probably that would be for the best | 13:47 |
| aelkner_ | sometimes writing a template is easier than trying to use the magic stuff that turns out to fail for a magic reason | 13:47 |
| yvl | I doubt you need batching and other features | 13:47 |
| aelkner_ | right | 13:48 |
| yvl | and speed is probably not an issue | 13:48 |
| yvl | also, no catalogs to speak of for report links | 13:48 |
| aelkner_ | right, more magic needed | 13:48 |
| yvl | yes, table formatter would be overkill | 13:48 |
| aelkner_ | so for now schooltool.gradebook has about ten reports, like you said | 13:49 |
| aelkner_ | so he view would be short | 13:49 |
| yvl | (I mentioned catalogs as a speedup for containers and a benefit of using table formatter - and you don't need speedup here) | 13:49 |
| aelkner_ | but what if the system grew in the next couple years | 13:49 |
| aelkner_ | and we eneded up with 100 reports | 13:50 |
| yvl | then we remade the view to use batched tables | 13:50 |
| aelkner_ | ok, so i don't worry about it for now | 13:50 |
| aelkner_ | do i even need to have filtering? | 13:50 |
| yvl | and report groups might be not enough by then | 13:50 |
| yvl | subgroups might get introduced, or something | 13:50 |
| aelkner_ | i'm not sure why you say report groups | 13:50 |
| yvl | (frankly, I think grouping is enough) | 13:50 |
| aelkner_ | i keep saying context type | 13:51 |
| aelkner_ | you say group | 13:51 |
| aelkner_ | are we talking about the same thing | 13:51 |
| yvl | context type -> Basic Person | 13:51 |
| yvl | group -> human readable type | 13:51 |
| yvl | that was another point in my email | 13:51 |
| yvl | human readable types != context types | 13:51 |
| aelkner_ | lke student versus teacher | 13:51 |
| yvl | a sad thing I found out when writing security descriptions :) | 13:52 |
| aelkner_ | but still, group is already a schooltool concept | 13:52 |
| aelkner_ | so i don't lke reusing it for this | 13:52 |
| aelkner_ | report type? | 13:52 |
| yvl | I already did :))) | 13:52 |
| yvl | in schooltool/security/* | 13:53 |
| yvl | you can name it type | 13:53 |
| yvl | or category | 13:53 |
| aelkner_ | ok, type it is | 13:53 |
| aelkner_ | now as far as the registration | 13:54 |
| aelkner_ | i would like to only have to register one adapter for each report | 13:54 |
| yvl | (now I suddenly started leaning towards "category") :)))))) | 13:54 |
| aelkner_ | category is ok | 13:54 |
| aelkner_ | now, getting back to the registration/lookup | 13:55 |
| aelkner_ | each report should only need to be registered once | 13:55 |
| aelkner_ | with all the info needed by either view | 13:55 |
| yvl | that I don't like | 13:55 |
| yvl | when you sit in Manage->Reports | 13:55 |
| yvl | you have traversed as far as SchoolToolApplication | 13:56 |
| yvl | and you have your request | 13:56 |
| yvl | you can look up an object | 13:56 |
| yvl | say school year | 13:56 |
| yvl | from the data model | 13:56 |
| yvl | and you can get it's absolute url | 13:56 |
| yvl | as in - the way to traverse to it | 13:56 |
| aelkner_ | yes, for all schoolyear reports, the urls wold be for the active schoolyear | 13:57 |
| yvl | and you can be bold and append "/request_reports.html" | 13:57 |
| yvl | now | 13:57 |
| aelkner_ | well for the schoolyear perhaps | 13:57 |
| yvl | when you get to the view, you never know what class it uses | 13:57 |
| yvl | or anything | 13:57 |
| aelkner_ | but not for a term | 13:57 |
| yvl | it might be skinned | 13:58 |
| aelkner_ | what class? | 13:58 |
| yvl | the view class | 13:58 |
| aelkner_ | what view class what uses? | 13:58 |
| yvl | you expect it to be your TermRequestReportView | 13:58 |
| aelkner_ | no | 13:58 |
| aelkner_ | you keep trying to do that | 13:58 |
| yvl | localhost/.../2011/request_reports.html | 13:58 |
| yvl | you never, ever know what's there | 13:59 |
| aelkner_ | we can't go directly to a report request view from the reference view | 13:59 |
| yvl | might be an empty page | 13:59 |
| yvl | ok | 13:59 |
| yvl | you go to the page | 13:59 |
| yvl | the reference view is there | 13:59 |
| yvl | or maybe it's not! | 14:00 |
| yvl | you never know that | 14:00 |
| aelkner_ | why would the reference view not be there? | 14:00 |
| yvl | somebody removed it | 14:00 |
| yvl | somebody skinned it | 14:00 |
| aelkner_ | fine take away the feature, what do we care? | 14:00 |
| aelkner_ | i don't see why they would want to remove the reports reference view for administrators | 14:01 |
| aelkner_ | but even if they did, what harm? | 14:01 |
| yvl | ok | 14:02 |
| yvl | let me put it this way | 14:02 |
| yvl | it doesn't matter that much to me now | 14:02 |
| yvl | it's wrong in my opinion to do it in a single adapter | 14:02 |
| yvl | but it would be a very long discussion to prove it | 14:02 |
| yvl | simply because it is really hard to explain things | 14:02 |
| yvl | that are very obvious to you | 14:03 |
| yvl | so you can do it either way | 14:03 |
| yvl | if you feel that having one adapter is easier to get things done | 14:04 |
| yvl | go for it :) | 14:04 |
| aelkner_ | it's not about easy to get things done | 14:04 |
| aelkner_ | it's ore about not making it overly complex forthe writer of the report to register it | 14:04 |
| yvl | that we can fix | 14:04 |
| yvl | we can write zcml directives | 14:05 |
| yvl | we can write helper methods | 14:05 |
| yvl | there is freedom in that | 14:05 |
| yvl | I really think I'll cook up some directive at some point :) | 14:05 |
| yvl | <schooltool:report /> | 14:06 |
| yvl | or maybe something else | 14:06 |
| yvl | but logically - those two adapters are separate for me | 14:06 |
| yvl | they work on different contexts | 14:06 |
| yvl | they work on different views | 14:06 |
| aelkner_ | adn teh idea would be that one directive would be enough for each report? | 14:06 |
| yvl | they share nothing | 14:06 |
| yvl | in the end - of course | 14:07 |
| yvl | well, using common sense | 14:07 |
| aelkner_ | and the meat code would register both adapters? | 14:07 |
| yvl | if we see that it takes a bazillion parameters, maybe there will be two :) | 14:07 |
| aelkner_ | meat | 14:07 |
| aelkner_ | meta | 14:07 |
| aelkner_ | i can't type in the right order | 14:07 |
| yvl | :))) | 14:08 |
| aelkner_ | am i right, though? | 14:08 |
| yvl | yes | 14:08 |
| yvl | I can't promise you that | 14:08 |
| yvl | I'm not a politician ;) | 14:08 |
| aelkner_ | ok, so i'll agree to create two adapters | 14:08 |
| yvl | but that's my intent | 14:08 |
| aelkner_ | on that adapts app so that the lookup returns all reports | 14:08 |
| aelkner_ | the other that adapts the actual context so that i can find the reports for the request view | 14:09 |
| aelkner_ | i'll have to register both, but eventually we'll replace them wth the directive, right? | 14:10 |
| yvl | it is very likely | 14:10 |
| yvl | I hate when you have to write myriads of zcml directives | 14:10 |
| yvl | it's a bad style :) | 14:10 |
| yvl | we will definitely bring this topic up in the sprint :) | 14:11 |
| aelkner_ | sure :) | 14:11 |
| yvl | the report topic | 14:11 |
| yvl | I was tossing with several ideas last year | 14:11 |
| yvl | so we might come up with something interesting | 14:12 |
| yvl | for example... | 14:12 |
| yvl | what if the report page would be a special directive | 14:12 |
| yvl | all pages know interfaces that they are built for | 14:12 |
| yvl | what if... we used catalogs of objects for quick lookup of all possible pdfs in the system... | 14:13 |
| yvl | or something along the lines | 14:13 |
| yvl | that would be interesting to search through | 14:14 |
| aelkner_ | catalogs of what objects? | 14:14 |
| yvl | all objects in the system | 14:15 |
| yvl | persons, schoolyears, everything :) | 14:15 |
| aelkner_ | use a catalog of oersons to find person reports? | 14:15 |
| yvl | use a super-catalog-of-everything | 14:16 |
| yvl | persons+schoolyears+groups+sections+crouses, etc. | 14:16 |
| aelkner_ | i see, sounds complex | 14:17 |
| yvl | it's a long shot :) | 14:17 |
| yvl | well, we'll see :) | 14:17 |
| aelkner_ | ok, to summaraize, and then i need to try to sleep again: | 14:17 |
| aelkner_ | for each report, i will register two adapters | 14:18 |
| aelkner_ | 1) for the context of the report that has the url and link text for the report request view | 14:18 |
| aelkner_ | 2) for ISchooltoolApplication that has the title, description, category and link for all three urls | 14:19 |
| yvl | umm | 14:19 |
| yvl | I suggest you re-use the IReportLink in both cases | 14:20 |
| yvl | with title/description/category/url | 14:20 |
| yvl | then you can re-use the Manage->Reports view for all request views | 14:21 |
| aelkner_ | ??? | 14:21 |
| aelkner_ | why do you keep wanting to merge the reference and the request views | 14:21 |
| yvl | hmm, you know | 14:22 |
| aelkner_ | the concepts are completely separate | 14:22 |
| aelkner_ | you can't reuse one view for the other | 14:22 |
| yvl | better use one adapter for now | 14:22 |
| aelkner_ | hugh?! | 14:22 |
| aelkner_ | no you're changing that idea back to what i suggested earlier? | 14:22 |
| yvl | I still want to merge reference and request views because they are identical | 14:23 |
| yvl | or will be in the future | 14:23 |
| yvl | likely | 14:23 |
| aelkner_ | look, i got to get something done here | 14:23 |
| yvl | ok then | 14:24 |
| yvl | <aelkner_> for each report, i will register two adapters | 14:24 |
| yvl | this | 14:24 |
| aelkner_ | so i have to have a simple definition of the task | 14:24 |
| yvl | but both implement same IReportLink | 14:24 |
| aelkner_ | the reference view is not a request view | 14:24 |
| yvl | right, sorry for doing this to you in the middle of the night | 14:24 |
| yvl | do not merge the views | 14:24 |
| yvl | but keep same IReportLink interface | 14:24 |
| aelkner_ | what does it have in it? | 14:25 |
| yvl | if you don't like it, make two interfaces | 14:25 |
| aelkner_ | your email does not cover both cases | 14:25 |
| yvl | it does, and it implies merger of request and reference views -- but I went too far there | 14:26 |
| aelkner_ | i would prefer IReportRequest and IReportRerefence | 14:26 |
| yvl | ok | 14:26 |
| yvl | that's fine :) | 14:26 |
| aelkner_ | the first has link text and url | 14:26 |
| aelkner_ | the second title, description, category and url for all three links in the row | 14:26 |
| aelkner_ | it's still an html table, just not a table formatter table | 14:27 |
| yvl | yep | 14:27 |
| aelkner_ | so IReportRequest will be registered fot the context and IReportRerefence for app | 14:28 |
| aelkner_ | sound right? | 14:28 |
| yvl | yes :) | 14:28 |
| aelkner_ | yay! | 14:28 |
| yvl | ;))))) | 14:28 |
| aelkner_ | btw, before i go, one last thing | 14:28 |
| aelkner_ | the idea is to move the Reports action link registrations for the various contexts out of schooltool.grabook | 14:29 |
| aelkner_ | and put them in schooltool.report | 14:29 |
| aelkner_ | one action link registration per context type | 14:29 |
| aelkner_ | the lnk would be the same in all cases, '/request_report.html' | 14:30 |
| aelkner_ | i could have one view class that i reuse for all the contexts | 14:30 |
| aelkner_ | and it can use the adpater fo self.context to get the report links | 14:31 |
| yvl | yes | 14:32 |
| yvl | the zcml should be in gradebook | 14:32 |
| yvl | because registers gradebooky things | 14:32 |
| aelkner_ | what i want to do is remove all of the zcml and view calsses from gradebook | 14:32 |
| yvl | but the view class implementation should be reused from schooltool.report | 14:32 |
| aelkner_ | and move them to schooltool.report | 14:33 |
| yvl | no | 14:33 |
| aelkner_ | the idea is that not only schooltool.gradebook | 14:33 |
| aelkner_ | but any package that wants to define a report need only define it and register the adapter | 14:33 |
| yvl | ah, then yes | 14:33 |
| aelkner_ | schooltool.report will be in change of registering the zcml for the action links and view classes, yes? | 14:34 |
| yvl | I misunderstood what classes you wanted to move to schooltool.report :) | 14:34 |
| aelkner_ | oh, ok | 14:34 |
| yvl | zcml that registers gradebook-related action links will be in gradebook | 14:34 |
| aelkner_ | what gradebook-related action links? | 14:35 |
| aelkner_ | you're confusing me again | 14:36 |
| yvl | for example - student reports | 14:36 |
| yvl | you can only make student reports if you have a gradebook | 14:37 |
| yvl | so - zcml that registers the student reports is written in gradebook | 14:37 |
| aelkner_ | oh, the pdf view classes them selves you speak of, rght? | 14:37 |
| yvl | the pdf view classes | 14:38 |
| yvl | and the adapters to IReportRequest and IReportReference | 14:38 |
| aelkner_ | and that's it | 14:38 |
| yvl | that point to those classes | 14:38 |
| yvl | yes | 14:38 |
| aelkner_ | cool, we're on the same page | 14:38 |
| yvl | cool :) | 14:38 |
| aelkner_ | ok, i will try to sleep now | 14:39 |
| aelkner_ | thanks for you input | 14:39 |
| yvl | good night aelkner_ | 14:39 |
| yvl | sorry for the fuss :) | 14:39 |
| aelkner_ | quite alright, we can always cut threw to the best solution | 14:39 |
| aelkner_ | did i just spell through as threw?!!! | 14:40 |
| aelkner_ | i AM tired | 14:40 |
| aelkner_ | anyway, zzzzzzzzzzzzzzzzzzzzzzzzzzz | 14:40 |
| yvl | good zzzzzzzzz to you then ;))) | 14:42 |
| *** yvl has quit IRC | 15:45 | |
| *** replaceafill has joined #schooltool | 16:42 | |
| *** ignas has quit IRC | 16:44 | |
| *** th1a has joined #schooltool | 16:46 | |
| replaceafill | aelkner_, zyt? | 17:27 |
| *** ignas has joined #schooltool | 18:10 | |
| *** ignas has quit IRC | 18:55 | |
| aelkner_ | replaceafill, hey | 20:44 |
| replaceafill | hey aelkner_ | 20:54 |
| replaceafill | i've been digging more and more in the gradebook, and i realized why you used key.startwith(...) | 20:55 |
| replaceafill | (Pdb) root.deployed.keys() | 20:57 |
| replaceafill | [u'2005-2006_spring', u'2005-2006_spring-2'] | 20:57 |
| replaceafill | both of them have to be deployed in new sections, and the key is '2005-2006', 'spring' | 20:58 |
| replaceafill | however this method breaks when you have terms that have similar names: quarter, quarter-2, quarter-3, etc | 20:59 |
| replaceafill | we would have deployed report sheets with ids like: | 21:00 |
| replaceafill | u'2005-2006_quarter', u'2005-2006_quarter-2', u'2005-2006_quarter-2-2'.... | 21:00 |
| replaceafill | good luck splitting by ('_') :( | 21:00 |
| *** th1a has quit IRC | 22:06 | |
| *** th1a has joined #schooltool | 22:06 | |
| *** fsufitch has joined #schooltool | 23:46 | |
Generated by irclog2html.py 2.15.1 by Marius Gedminas - find it at mg.pov.lt!