dgets / lasttime Goto Github PK

Having to type the full url + app & view name is getting to be a real pain in the butt. Might as well take a second and do this the right way, as in the full app navigation will be an important feature.

No scaling exists here yet, so the bars will be running off of the page when checking out the information on any medications that are dosed in high units. Get the scaling cleared up.

Finally got database insertion working (at least once); need to add the detail view in order to get the main/index view rendering again now.

Unlike in the other django app that I'm working on, this one has all of the navigation information added as static links within the navbar. This, obviously, needs to be changed. Get the navigation information added to the models somewhere for proper nav loading.

Pretty self-explanatory, I think. Just bring everything up-to-date here.

For new substances that don't have any administrations there is a divide by 0 error that is hosing things due to not taking this into account at the following line usage_average = total_administered / usage_count. Set up a case for no administrations.

We need a view that is going to return just the JSON required for the graphing statistics, in order to feed to the D3 graphing library. Using embedded script & tags is definitely not the way to be handling that.

See also working with JSON and Django.

NOTE: This is en route to #26.

This particular view needs to be invoked with an int pk. Being as the navbar only sends it to a hard-coded page, it always says that there are no results. It should be only invoked from the appropriate linked entries in other apps, at least at this point.

Header information, much like the navbar info in issue #28, needs to be added to the database, so that changes in this data can be made easily, without having to change every instance of the static HTML in every one of the views.

This project has had versions up for release at this point, and it's gotten a little bit of attention, at least on Diaspora. This means that people could be coming along and wanting to take a look at the capabilities and screenshots of the application, as well as a general synopsis. Get this information into the wiki so that people can find the documentation that they may be looking for.

The data_summary.html template is getting a little nasty; relocate any named function definitions to the external JS file that's loaded.

Processing in views.py is not pulling the correct information regarding averages, total administrations, and the like. It looks like a QuerySet is being returned as the initial substance name, so that might be a pointer for which direction to be looking in here.

In recadm.add's view (views.py), I am chopping up some data to reduce network traffic before sending it to the template rendering. In the index view, the piecemeal data is put together into mydata without any issues, utilizing a list of dictionaries. When I try to do the same thing, with the exact same methodology, below, in the add view, I'm getting the following error:

File "/home/sprite/src/py/django/lasttime/recadm/views.py", line 36, in add
mydata.add({'name': sub.common_name, 'id': sub.id, })
AttributeError: 'list' object has no attribute 'add'

So yeah, I've not slept in too long, so I'm just going to halt here before I start making things really ugly. No doubt I'm missing something horribly obvious.

Upon recording of a new substance administration, recadm states that there are no administrations recorded. However, reloading the recadm:index view clearly shows that the records have been added properly.

Realized a bit ago that at least a few of the database models were missing custom str() methods for general record & admin view display. Get these done for a little friendlier experience.

There are starting to be enough particulars to this project that aren't precisely intuitive so that we really need to add an online documentation view. Along with this, since this application can potentially be used in situations where medical harm could arise, we need to insert disclaimer information regarding the algorithms being experimental, and how nobody should attempt to change any medication levels or anything of the sort without a physician's explicit instructions.

I think that this is just primarily the administration records that need to be handled on a per-user basis. Run through and check to see if anything else needs to be handled that way, as well, though.

Not sure how to fix this, I'm beyond the tutorial that I was using now... Anyway I'm trying to record the administration of a substance (by its id field), within the 'usage' or 'administration' record that I'm creating. Not quite sure how to get this laid out so Django will be happy with it:

class Usage(models.Model):
    sub = models.ForeignKey(Substance)
    dosage = models.IntegerField()
    timestamp = models.DateTimeField('time administered', default=timezone.now)
    notes = models.CharField(max_length=160)

Also, there is no template for addentry.html, so when the entry is not added to the db, there is no view to render with an error message.

This should be completely removed from the display until we have the lipid solubility half-life calculation algorithm implemented, as the water-soluble target for elimination that it displays is completely bogus.

Implementation will consist of a couple of primary features; one that will be fairly simple for alpha, and a much more complicated one, probably requiring the addition of JavaScript libraries, which will add the icing on the cake-- graphing the beginnings of the data that we're really here to see.

NOTE: This is going to be handled with class-based generic views, which will steepen the learning curve for a bit but keep providing me with new material for better Django in the future.

• create initial app with the ability to see various tabulated data regarding all previous administrations of a particular substance; ie initial dosage date, number of total dosages, average time between dosages, highest/lowest dosage details, average dosage amount (alpha version)
• add the gravy; utilize some libraries for graphing and add the formulas for half-life plasma dispersal to the mix and let's take a look at the plasma drop-offs between dosages; that is one of the things that we're really writing this app for, after all (this'll be beta)

See also issue #9, a subset of the initial checkbox's features.

Only the dosages are currently graphed. Add the intervals between, as well.

Everything is packed together in there and it's a mess; break things up properly.

Not sure where exactly these will be, but the old MS-DOS CGA THC Calculator app, that existed back in the mid 90s, if nothing else, should provide a rough outline of what will be needed. It may, of course, vary per chemical solubility and/or binding method in the pork mayo.

A reddit post in the appropriate subreddit can probably turn this up, as well...

The footers are in place for the recadm app (see #31), but there is no inter-app navigation footer in place anywhere else. Even in places where navigation is not necessary within the app, there should still be a <div> in place to keep the appearance uniform. It'll give a much better impression of a contained single-page as an application as opposed to a standard web page that may or may not be able to be scrolled.

Now that things are starting to be somewhat worth using on this project, it would be nice to spice up the font selection in a bit of a professional kind of way. Get on Google fonts and try to figure out a nice selection of a few that aren't the standard defaults, but still look nice in this setting.

While the formulas for the actual dispersal of the lipid soluble metabolite from the adipose tissue (see issue #13) are still eluding me, it may be useful to implement a much more rudimentary view. I was thinking of one that goes through the past intervals between dosages, and if the recent one(s) have been less than the full 5.7 half-lives apart, it could at least notify the user that it will be taking longer than the standard half-life. On the other hand, if usage has not been as frequent, it could inform the user of the target date where the metabolites will be cleared, or if they have already been cleared. Along with, of course, a warning that these results are based on an experimental algorithm, and not to trust them in any sort of vital or important situation.

It probably won't be much tougher than just throwing whatever field, like in this case the Substance.common_name field into the parameters for views.py, but whatever has to be done in order to access the other app's data from the templates still has yet to be done.

Yay mangled grammar.

Obviously, as this is web based, it will be necessary to have multiple user support. Thus it is time to add this.

See also: Django user authentication and authorization

Something has hosed what was previously working in these apps, at least in the feature/navigation-via-database branch. Need to figure out what's going on there...

For this to be of any use, we need to at least know:

• the half-life of the substance in the blood, based on the detectable metabolites
• the biologically active original/active metabolites in the blood (should default to the detectable metabolite period)
• whether or not the substance is fat soluble

Having a bit of problem in getting the parameters (I think) correct in my {% url 'dataview:dump_graph_data' sub.id %} area from within the script tags where I want to render the graph. This resides in dataview/templates/dataview/data_summary.html, precisely where the graph is to be embedded.

Not totally sure about why the reverse match isn't working, but I think that it has something to do with the parameters not being structured properly with the rest of the URL. See the following error message:

django.urls.exceptions.NoReverseMatch: Reverse for 'dump_graph_data' with arguments '('',)' not found. 1 pattern(s) tried: ['dataview\/dump_graph_data\/(?P<sub_id>[0-9]+)\/$']

Average dosage time, maybe measures of the rate of decrease/increase comparatively, etc...

The recadm app (and possibly subadd, not sure about that yet, though) is missing any sort of links within the app for navigating between the index/detail views and the add view. This needs to be fixed.

In both recadm and subadd (and presumably functionality yet to come), time units and measurements are both stored in a tuple format for some reason. It would be much easier to use and legible to use the same Enum format that is currently being used in nightMiner. Make it so.

Initial graphing works as of commit # a2af235, but the axis needs to be rotated 90 degrees and we need labels for the different axes. Going to probably be switching to an SVG view instead of strictly HTML in order to get some more features for the labeling and the like. Trying to use the example code at this tutorial in order to get things working, but it's proving a little more problematic than the simple (incorrectly oriented) graph that we did in HTML previously.

If this page is accessed without the appropriate context, an error page appears. It should just redirect back to the add view, or display some sort of error about not appropriately navigating to the page after adding a new substance.

Dosages are currently only accepting integers, in a drop-down menu. This should be fixed so that floats can be entered in normal decimal form (ie .25 or 0.25).

En route to #43, it appears that for some reason the json library is refusing to serialize the decimal values for the dosages stored in the database. Wrapping the values in int() works, as apparently int is serializable, but that doesn't get us the granularity that we're going to need in looking at this data; the fractional values may be important.

We could just multiply by powers of ten until everything is an integer, and pass the multiplier along in the JSON in case it's needed for anything. Wish I understood why decimal values won't serialize into JSON here, not that it changes the problem at all.

detail() got an unexpected keyword argument 'topic_id'

is showing up on the error page when trying to view the details on an administration record.

It's not always going to be in mg. Got to create an enum (or equivalent) and add a drop down next to dosage for the units & add it to the model, forms, etc.

Unable to save to the database for an unknown reason. Such a very helpful error message. I should probably start looking for specific exceptions. Haven't had a chance to do that in python just yet. Anyway, the saving & adding record logic in the recadm app should be just about completed, as soon as this stumbling block is out of the way.

Everything is pulling from the static file in their own app tree right now. This should be changed so that each particular app is pulling from the static file in the app's main static file area.

  File "/home/sprite/src/py/django/lasttime/recadm/urls.py", line 3, in <module>
    from . import views
  File "/home/sprite/src/py/django/lasttime/recadm/views.py", line 5, in <module>
    from .forms import UsageForm
  File "/home/sprite/src/py/django/lasttime/recadm/forms.py", line 4, in <module>
    class UsageForm(forms.Form):
  File "/home/sprite/src/py/django/lasttime/recadm/forms.py", line 5, in UsageForm
    sub = forms.ForeignKey('subadd.Substance', on_delete=models.CASCADE)
AttributeError: module 'django.forms' has no attribute 'ForeignKey'

No workee; having trouble finding a concise resource on what I should be looking at instead of ForeignKey here... It may well help things out a little bit to check into the validity of on_delete=models.CASCADE in forms.py, as well. Somehow I think that if it actually is necessary, it'll at least look a little different-- say an s/models/forms/, if nothing else...

This came about while trying to implement a solution for #8.

Upon loading the dataview:index view, a listing of the most recent administrations is supposed to appear, hyperlinking to the applicable dataview:data_summary views for each associated entry. Unfortunately, nothing seems to be appearing at this point, just the helpful message that "No relevant records are available."

This is to be completed en route to #56.

After getting the bit coded into the halflife routines for detectable and full elimination target date/times, it seems that there must be a bit of inconsistency in the formulas that I'm using. I was told by one of my doctors that full elimination of a substance is normally counted as 5.7 * halflife. Unfortunately, at least in the case of THC, this means that complete elimination takes less time than detectable elimination.

This is, no doubt, due to the fact that the halflife for delta-9 THC is so short, and the fact that it's actually THC-COOH, a secondary or tertiary byproduct of the metabolism, that is tested for. So something needs to at least be coded into the view/template to check and see if full elimination is prior to detectable elimination and print an explanatory message to the user.

It'd be really nice to have a table of secondary/tertiary metabolites that come into play, but that's really not feasible at this point in the game.

The next step in adding multi-user support now that we've got authentication working. Need to run through each individual view for this and add the decorator @login_required for functional views or LoginRequiredMixin to I think it's the parameters for a class-based view.

{% extends "whatever.html" %} is your friend. I was looking for something with that functionality for awhile, but only just now stumbled across it. So it's definitely time to wipe out the repeated crap in each of the templates and just embed a standard header/footer in each fragment.

None of the timespan information, which is supposed to be recorded between administrations 1-2, 2-3, 3-4..., is available to the data_summary view. I believe this is due to the datetime object's requirements for special processing; things don't just break down into a regular integer mathematical operation, as can be seen on the python datetime object page's information.

We'll have to be utilizing datetime.timedelta() in order to determine how long has gone between administrations, and there will probably have to be template modifications made, or else the timedelta() results will have to be massaged in views.py, in order to display things correctly, as [again] we're not just passing a simple data type.

NOTE: This issue is a block en route to #26.

Running into the same problem that I originally had from #5 again, now that I've switched from using models & forms separately in subadd to utilizing ModelForms to avoid redundancy. This is in trying to find the proper solution to #11, which I just closed, as everything seems to be working, except for accessing the query of the Substance records.