1. Last 7 days
    1. Reviewer #3 (Public Review):

      Summary:

      The authors have devised an elegant stopped-flow fluorescence approach to probe the mechanism of action of the Hsp100 protein unfoldase ClpB on an unfolded substrate (RepA) coupled to 1-3 repeats of a folded titin domain. They provide useful new insight into the kinetics of ClpB action. The results support their conclusions for the model setup used.

      Strengths:

      The stopped-flow fluorescence method with a variable delay after mixing the reactants is informative, as is the use of variable numbers of folded domains to probe the unfolding steps.

      Weaknesses:

      The setup does not reflect the physiological setting for ClpB action. A mixture of ATP and ATPgammaS is used to activate ClpB without the need for its co-chaperones, Hsp70. Hsp40 and an Hsp70 nucleotide exchange factor. This nucleotide strategy was discovered by Doyle et al (2007) but the mechanism of action is not fully understood. Other authors have used different approaches. As mentioned by the authors, Weibezahn et al used a construct coupled to the ClpA protease to demonstrate translocation. Avellaneda et al used a mutant (Y503D) in the coiled-coil regulatory domain to bypass the Hsp70 system. These differences complicate comparisons of rates and step sizes with previous work. It is unclear which results, if any, reflect the in vivo action of ClpB on the disassembly of aggregates.

    2. eLife assessment

      This valuable study presents the development of a single turnover stopped-flow fluorescence experiment to study the kinetics of substrate unfolding and translocation by the bacterial ClpB disaggregase. Using non-physiological nucleotides to bypass the physiological regulation mechanism of ClpB, the authors convincingly show that the ClpB disaggregase is a processive motor with a slow unfolding step preceding rapid translocation. The results of this analysis are of value for future mechanistic studies on energy-dependent unfolding, degradation, and disaggregation molecular machines.

    3. Reviewer #1 (Public Review):

      In this study, the authors used a stopped-flow method to investigate the kinetics of substrate translocation through the channel in hexameric ClpB, an ATP-dependent bacterial protein disaggregase. They engineered a series of polypeptides with the N-terminal RepA ClpB-targeting sequence followed by a variable number of folded titin domains. The authors detected translocation of the substrate polypeptides by observing the enhancement of fluorescence from a probe located at the substrate's C-terminus. The total time of the substrates' translocation correlated with their lengths, which allowed the authors to determine the number of residues translocated by ClpB per unit time.

      Strengths:

      This study confirms a previously proposed model of processive translocation of polypeptides through the channel in ClpB. The novelty of this work is in the clever design of a series of kinetic experiments with an engineered substrate that includes stably folded domains. This approach produced a quantitative description of the reaction rates and kinetic step sizes. Another valuable aspect is that the method can be used for other translocases from the AAA+ family to characterize their mechanism of substrate processing.

      Weaknesses:

      The main limitation of the study is in using a single non-physiological substrate of ClpB, which does not replicate the physical properties of the aggregated cellular proteins and includes a non-physiological ClpB-targeting sequence. Another limitation is in the use of ATPgammaS to stimulate the substrate processing. It is not clear how relevant the results are to the ClpB function in living cells with ATP as the source of energy, a multitude of various aggregated substrates without targeting sequences that need ClpB's assistance, and in the presence of the co-chaperones.

      The authors do not attempt to correlate the kinetic step sizes detected during substrate translocation and unfolding with the substrate's structure, which should be possible, given how extensively the stability and unfolding of the titin I27 domain were studied before. Also, since the substrate contains up to three I27 domains separated with unstructured linkers, it is not clear why all the translocation steps are assumed to occur with the same rate constant.

      Some conclusions presented in the manuscript are speculative:

      The notion that the emission from Alexa Fluor 555 is enhanced when ClpB approaches the substrate's C-terminus needs to be supported experimentally. Also, evidence that ATPgammaS without ATP can provide sufficient energy for substrate translocation and unfolding is missing in the paper.

    4. Reviewer #2 (Public Review):

      Summary:

      The current work by Banwait et al. reports a fluorescence-based single turnover method based on protein-induced fluorescence enhancement (PIFE) to show that ClpB is a processive motor. The paper is a crucial finding as there has been ambiguity on whether ClpB is a processive or non-processive motor. Optical tweezers-based single-molecule studies have shown that ClpB is a processive motor, whereas previous studies from the same group hypothesized it to be a non-processive motor. As co-chaperones are needed for the motor activity of the ClpB, to isolate the activity of ClpB, they have used a 1:1 ratio ATP and ATPgS, where the enzyme is active even in the absence of its co-chaperones, as previously observed. A sequential mixing stop-flow protocol was developed, and the unfolding and translocation of RepA-TitinX, X = 1,2,3 repeats was monitored by measuring the fluorescence intensity with the time of Alexa F555 which was labelled at the C-terminal Cysteine. The observations were a lag time, followed by a gradual increase in fluorescence due to PIFE, and then a decrease in fluorescence plausibly due to the dissociation from the substrate allowing it to refold. The authors observed that the peak time depends on the substrate length, indicating the processive nature of ClpB. In addition, the lag and peak times depend on the pre-incubation time with ATPgS, indicating that the enzyme translocates on the substrates even with just ATPgS without the addition of ATP, which is plausible due to the slow hydrolysis of ATPgS. From the plot of substrate length vs peak time, the authors calculated the rate of unfolding and translocation to be ~0.1 aas-1 in the presence of ~1 mM ATPgS and increases to 1 aas-1 in the presence of 1:1 ATP and ATPgS. The authors have further performed experiments at 3:1 ATP and ATPgS concentrations and observed ~5 times increase in the translocation rates as expected due to faster hydrolysis of ATP by ClpB and reconfirming that processivity is majorly ATP driven. Further, the authors model their results to multiple sequential unfolding steps, determining the rate of unfolding and the number of amino acids unfolded during each step. Overall, the study uses a novel method to reconfirm the processive nature of ClpB.

      Strengths:

      (1) Previous studies on understanding the processivity of ClpB have primarily focused on unfolded or disordered proteins; this study paves new insights into our understanding of the processing of folded proteins by ClpB. They have cleverly used RepA as a recognition sequence to understand the unfolding of titin-I27 folded domains.

      (2) The method developed can be applied to many disaggregating enzymes and has broader significance.

      (3) The data from various experiments are consistent with each other, indicating the reproducibility of the data. For example, the rate of translocation in the presence of ATPgS, ~0.1 aas-1 from the single mixing experiment and double mixing experiment are very similar.

      (4) The study convincingly shows that ClpB is a processive motor, which has long been debated, describing its activity in the presence of only ATPgS and a mixture of ATP and ATPgS.

      (5) The discussion part has been written in a way that describes many previous experiments from various groups supporting the processive nature of the enzyme and supports their current study.

      Weaknesses:

      (1) The authors model that the enzyme unfolds the protein sequentially around 60 aa each time through multiple steps and translocates rapidly. This contradicts our knowledge of protein unfolding, which is generally cooperative, particularly for titinI27, which is reported to unfold cooperatively or utmost through one intermediate during enzymatic unfolding by ClpX and ClpA.

      (2) It is also important to note that the unfolding of titinI27 from the N-terminus (as done in this study) has been reported to be very fast and cannot be the rate-limiting step as reported earlier(Olivares et al, PNAS, 2017). This contradicts the current model where unfolding is the rate-limiting step, and the translocation is assumed to be many orders faster than unfolding.

      (3) The model assumes the same time constant for all the unfolding steps irrespective of the secondary structural interactions.

      (4) Unlike other single-molecule optical tweezer-based assays, the study cannot distinguish the unfolding and translocation events and assumes that unfolding is the rate-limiting step.

    1. user?apik

      Линейки нет.

    2. ее

      А ведь, наверное, не ее, а его? Идентификатор.

    1. “If I can predict all of your beliefs from one of your beliefs, you’re not a serious thinker.” — Chris WilliamsonBeing pro-choice and being pro-gun-control don’t necessarily follow from each other, yet those who believe one usually also believe the other. This is because most people don’t choose beliefs individually but subscribe to “packages” of beliefs offered by a tribe.
    2. 3. Fredkin's ParadoxThe more similar two choices seem, the less the decision should matter, yet the harder it is to choose between them. As a result, we often spend the most time on the decisions that matter least. To avoid being paralyzed by meaningless choices, use decision-making heuristics.
    1. 2.1 Richtlijnen voor het ontwikkelen van een OTL

      Ik vind de volgorde van de paragraven onduidelijk 2.1 gaat over een OTL, 2;.2 over een woordenboek en 2.3 over een ontologie (= weer OTL). Misschien is het goed eerst de niveaus te beschrijven waarop je een OTL kan bouwen? Dus van woordenboek (thesaurus) door het toevoegen van relaties naar een ontologie? Ik mis eigenlijk een inhoudelijk inleidend hoofdstuk.

    2. semantische informatiemodellen

      Hier wordt gesproken over 'Semantische informatiemodellen', eerder over OTL'en. Je kunt het ook nog ontologieën noemen. Ik zou ergens in het begin zeggen dat dat allemaal hetzelfde is.

    3. een diversiteit van gebruik van bestandsformaten

      Volgens mij is dat problematiek die niet direct met een OTL te maken heeft, maar meer met het feit dat het na het wegvallen van COINS ontbreekt aan een uitwisselstandaard voor areaalgegevens.

    1. Résumé de la vidéo [00:00:00][^1^][1] - [00:50:47][^2^][2]:

      Cette vidéo présente les bienfaits de la cohérence cardiaque pour la gestion du stress et d'autres aspects de la santé. Caroline Sévoz-Couche, neuropharmacologue, explique les mécanismes physiologiques derrière cette technique de respiration et ses effets sur le corps et l'esprit.

      Points forts : + [00:00:00][^3^][3] Introduction à la cohérence cardiaque * Présentation de Caroline Sévoz-Couche * Importance de la cohérence cardiaque * Objectifs de la présentation + [00:01:00][^4^][4] Mécanismes physiologiques * Explication du nerf vague * Fréquence respiratoire optimale * Effets sur les organes et le cerveau + [00:14:00][^5^][5] Avantages de la cohérence cardiaque * Amélioration de la concentration * Réduction du stress * Effets bénéfiques prouvés scientifiquement + [00:25:00][^6^][6] Applications pratiques * Utilisation avant les compétitions sportives * Techniques de respiration spécifiques * Importance de la respiration nasale + [00:37:00][^7^][7] Recommandations et outils * Durée et fréquence des séances * Applications et dispositifs recommandés * Conseils pour intégrer la cohérence cardiaque dans la vie quotidienne

    1. Reviewer #1 (Public Review):

      V.Mischley et al have applied several simple machine learning (ML)frameworks (which were widely used before the advent of deep learning methods) to distinguish (as the authors claimed) between interacting and non-interacting pairs. For this purpose, the authors have generated two sets of protein pairs, equal in their size (which is preferable for classification problems in ML). The first set comprises a non-redundant set of interacting proteins from the DOCKGROUND database, and the second set consists of presumably non-interacting protein pairs. Then, the authors trained and evaluated compared performance of the utilized ML frameworks using a set of well-described parameters. The authors also demonstrated the superior performance of their method in comparison to other metrics, such as ipTM and pdockQ. Finally, the authors applied their method to identify interacting pairs within the tumor necrosis factor superfamily. In general, the paper is well written, and the methodology applied is sound, however, I have a fundamental concern regarding the non-interacting set. As follows from the author's description, this set does not ensure that generated protein pairs do not interact as follows from the main paradigm of template-based docking (structurally similar proteins have similar binding modes). In my opinion, this set rather presents a set of non-cognate or weekly interacting protein pairs. That also explains the drop in performance for the pDockQ metric on the authors' set (AUC 0.71 in this paper opposite t0 0.87 in the original paper), as pDockQ was trained on the set of truly non-interacting proteins. In that respect, it would be interesting to see the performance of the authors' approach, but trained on the set described in the pDockQ paper (more or less the same set of interacting pairs but a different set of non-interacting proteins).

    2. Reviewer #2 (Public Review):

      Summary:

      In this paper, the authors train a simple machine learning to improve the ability of AlphaFold-multimers ability to separate interacting from non-interacting pairs. The improvement is small compared with the default AlphaFold score (AUROC from 0.84 to 0.88).

      Strengths:

      The dataset seems to be carefully constructed.

      Weaknesses:

      The comparison with the state of the art is limited.<br /> - pDockQ comparison is (likely) incorrect (v2.1 should be used, not v1.0).<br /> - Comparison with ipTM should be complemented with RankingConfidence (the default AF2-score).<br /> - Several other scores than pDockQ have been developed for this task.<br /> - Other methods (by Jianlin Chen) to "improve" quality assessment of AF2-models have been presented - these should at least be cited.

      Lack of ablation studies:

      - Quite likely the most significant contributor is the ipTM (and other scores from AF2). This should be analyzed and discussed.

      Lack of data:

      - The GitHub repository does not contain the models - so the data can not be examined carefully. Nor can the model be retrained.

      - No license is provided for the code in the Git repository.

    3. Reviewer #3 (Public Review):

      Due to AlphaFold's popularity, I see people taking the fact that AlphaFold predicted a decent protein complex structure between two proteins as strong support for protein-protein interaction (PPI) and even using such a hypothesis to guide their experimental studies. The scientific community needs to realize that just like the experimental methods to characterize PPIs, using AlphaFold to study PPIs has a considerate false positive and false negative rate.

      Overall, I think it is solid work, but I have several concerns.

      (1) In the benchmark set, the authors used about 1:1 ratio of positive (active) and negative controls. However, in real-life applications, the signal-to-noise ratio of PPI screening is very low. As they stated in their very nice introduction, there are expected to be "74,000 - 200,000" true PPIs in humans, whereas there are > 200,000,000 protein pairs. I am not suggesting that the authors need to make their tool able to handle such a high noise level, but at least some discussion along this line is helpful.

      (2) The benchmark set from Dockground mostly consists of stable interactions that are actually relatively easily distinguished from non-interacting pairs. I suggest the authors test how well their tools will perform on weaker and transient interactions or discuss this limitation. For the more stable complexes, structural features at the interface are useful in predicting whether two proteins should interact, but I doubt this will be true for weaker and transient interactions.

      (3) Given that the 1:1 benchmark set is a simplified task (see the first point) compared to real-life applications, the other task shown in this paper, i.e., the ligand/receptor pairings, seems to be more important. I think it is necessary to compare their tool against other simpler metrics for this more realistic task.

    1. API Reference ViewSet The ViewSet class inherits from APIView. You can use any of the standard attributes such as permission_classes, authentication_classes in order to control the API policy on the viewset. The ViewSet class does not provide any implementations of actions. In order to use a ViewSet class you'll override the class and define the action implementations explicitly. GenericViewSet The GenericViewSet class inherits from GenericAPIView, and provides the default set of get_object, get_queryset methods and other generic view base behavior, but does not include any actions by default. In order to use a GenericViewSet class you'll override the class and either mixin the required mixin classes, or define the action implementations explicitly. ModelViewSet The ModelViewSet class inherits from GenericAPIView and includes implementations for various actions, by mixing in the behavior of the various mixin classes. The actions provided by the ModelViewSet class are .list(), .retrieve(), .create(), .update(), .partial_update(), and .destroy(). Example Because ModelViewSet extends GenericAPIView, you'll normally need to provide at least the queryset and serializer_class attributes. For example: class AccountViewSet(viewsets.ModelViewSet): """ A simple ViewSet for viewing and editing accounts. """ queryset = Account.objects.all() serializer_class = AccountSerializer permission_classes = [IsAccountAdminOrReadOnly] Note that you can use any of the standard attributes or method overrides provided by GenericAPIView. For example, to use a ViewSet that dynamically determines the queryset it should operate on, you might do something like this: class AccountViewSet(viewsets.ModelViewSet): """ A simple ViewSet for viewing and editing the accounts associated with the user. """ serializer_class = AccountSerializer permission_classes = [IsAccountAdminOrReadOnly] def get_queryset(self): return self.request.user.accounts.all() Note however that upon removal of the queryset property from your ViewSet, any associated router will be unable to derive the basename of your Model automatically, and so you will have to specify the basename kwarg as part of your router registration. Also note that although this class provides the complete set of create/list/retrieve/update/destroy actions by default, you can restrict the available operations by using the standard permission classes. ReadOnlyModelViewSet The ReadOnlyModelViewSet class also inherits from GenericAPIView. As with ModelViewSet it also includes implementations for various actions, but unlike ModelViewSet only provides the 'read-only' actions, .list() and .retrieve(). Example As with ModelViewSet, you'll normally need to provide at least the queryset and serializer_class attributes. For example: class AccountViewSet(viewsets.ReadOnlyModelViewSet): """ A simple ViewSet for viewing accounts. """ queryset = Account.objects.all() serializer_class = AccountSerializer Again, as with ModelViewSet, you can use any of the standard attributes and method overrides available to GenericAPIView. Custom ViewSet base classes You may need to provide custom ViewSet classes that do not have the full set of ModelViewSet actions, or that customize the behavior in some other way. Example To create a base viewset class that provides create, list and retrieve operations, inherit from GenericViewSet, and mixin the required actions: from rest_framework import mixins, viewsets class CreateListRetrieveViewSet(mixins.CreateModelMixin, mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet): """ A viewset that provides `retrieve`, `create`, and `list` actions. To use it, override the class and set the `.queryset` and `.serializer_class` attributes. """ pass By creating your own base ViewSet classes, you can provide common behavior that can be reused in multiple viewsets across your API.

      Let's simplify the API reference for different ViewSet classes in Django REST Framework with examples.

      ViewSet

      The ViewSet class is like a controller. It doesn't provide any built-in actions (like list, create, etc.). You need to define these actions yourself.

      • Attributes: You can use attributes like permission_classes, authentication_classes to control access to the ViewSet.

      Example:

      ```python from rest_framework import viewsets from rest_framework.response import Response

      class CustomViewSet(viewsets.ViewSet): permission_classes = [IsAuthenticated]

      def list(self, request):
          pass  # Your logic here
      
      def retrieve(self, request, pk=None):
          pass  # Your logic here
      

      ```

      GenericViewSet

      The GenericViewSet class inherits from GenericAPIView and provides default methods like get_object and get_queryset, but it doesn't include actions by default. You need to mix in the required actions or define them explicitly.

      Example:

      ```python from rest_framework import mixins, viewsets

      class CustomGenericViewSet(mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet): queryset = YourModel.objects.all() serializer_class = YourSerializer ```

      ModelViewSet

      The ModelViewSet class inherits from GenericAPIView and includes implementations for common actions like list, retrieve, create, update, partial_update, and destroy.

      Example:

      ```python from rest_framework import viewsets from yourapp.models import Account from yourapp.serializers import AccountSerializer from yourapp.permissions import IsAccountAdminOrReadOnly

      class AccountViewSet(viewsets.ModelViewSet): queryset = Account.objects.all() serializer_class = AccountSerializer permission_classes = [IsAccountAdminOrReadOnly] ```

      You can also customize the queryset dynamically:

      ```python class AccountViewSet(viewsets.ModelViewSet): serializer_class = AccountSerializer permission_classes = [IsAccountAdminOrReadOnly]

      def get_queryset(self):
          return self.request.user.accounts.all()
      

      ```

      ReadOnlyModelViewSet

      The ReadOnlyModelViewSet class provides only read-only actions (list and retrieve).

      Example:

      ```python from rest_framework import viewsets from yourapp.models import Account from yourapp.serializers import AccountSerializer

      class AccountViewSet(viewsets.ReadOnlyModelViewSet): queryset = Account.objects.all() serializer_class = AccountSerializer ```

      Custom ViewSet Base Classes

      You can create custom base classes by mixing in the required actions from mixins.

      Example:

      ```python from rest_framework import mixins, viewsets

      class CreateListRetrieveViewSet(mixins.CreateModelMixin, mixins.ListModelMixin, mixins.RetrieveModelMixin, viewsets.GenericViewSet): """ A viewset that provides retrieve, create, and list actions.

      To use it, override the class and set the `.queryset` and
      `.serializer_class` attributes.
      """
      pass
      

      ```

      Summary

      • ViewSet: Basic controller, no built-in actions. You define them yourself.
      • GenericViewSet: Provides default methods but no actions. You mix in or define actions.
      • ModelViewSet: Provides common actions (list, retrieve, create, update, partial_update, destroy).
      • ReadOnlyModelViewSet: Provides read-only actions (list, retrieve).
      • Custom ViewSet: Create your own by mixing in actions from mixins.

      These tools help you manage and organize the API logic more effectively in Django REST Framework.

    2. If we need to, we can bind this viewset into two separate views, like so: user_list = UserViewSet.as_view({'get': 'list'}) user_detail = UserViewSet.as_view({'get': 'retrieve'}) Typically we wouldn't do this, but would instead register the viewset with a router, and allow the urlconf to be automatically generated. from myapp.views import UserViewSet from rest_framework.routers import DefaultRouter router = DefaultRouter() router.register(r'users', UserViewSet, basename='user') urlpatterns = router.urls Rather than writing your own viewsets, you'll often want to use the existing base classes that provide a default set of behavior. For example: class UserViewSet(viewsets.ModelViewSet): """ A viewset for viewing and editing user instances. """ serializer_class = UserSerializer queryset = User.objects.all() There are two main advantages of using a ViewSet class over using a View class. Repeated logic can be combined into a single class. In the above example, we only need to specify the queryset once, and it'll be used across multiple views. By using routers, we no longer need to deal with wiring up the URL conf ourselves. Both of these come with a trade-off. Using regular views and URL confs is more explicit and gives you more control. ViewSets are helpful if you want to get up and running quickly, or when you have a large API and you want to enforce a consistent URL configuration throughout. ViewSet actions The default routers included with REST framework will provide routes for a standard set of create/retrieve/update/destroy style actions, as shown below: class UserViewSet(viewsets.ViewSet): """ Example empty viewset demonstrating the standard actions that will be handled by a router class. If you're using format suffixes, make sure to also include the `format=None` keyword argument for each action. """ def list(self, request): pass def create(self, request): pass def retrieve(self, request, pk=None): pass def update(self, request, pk=None): pass def partial_update(self, request, pk=None): pass def destroy(self, request, pk=None): pass Introspecting ViewSet actions During dispatch, the following attributes are available on the ViewSet. basename - the base to use for the URL names that are created. action - the name of the current action (e.g., list, create). detail - boolean indicating if the current action is configured for a list or detail view. suffix - the display suffix for the viewset type - mirrors the detail attribute. name - the display name for the viewset. This argument is mutually exclusive to suffix. description - the display description for the individual view of a viewset. You may inspect these attributes to adjust behavior based on the current action. For example, you could restrict permissions to everything except the list action similar to this: def get_permissions(self): """ Instantiates and returns the list of permissions that this view requires. """ if self.action == 'list': permission_classes = [IsAuthenticated] else: permission_classes = [IsAdminUser] return [permission() for permission in permission_classes] Marking extra actions for routing If you have ad-hoc methods that should be routable, you can mark them as such with the @action decorator. Like regular actions, extra actions may be intended for either a single object, or an entire collection. To indicate this, set the detail argument to True or False. The router will configure its URL patterns accordingly. e.g., the DefaultRouter will configure detail actions to contain pk in their URL patterns. A more complete example of extra actions: from django.contrib.auth.models import User from rest_framework import status, viewsets from rest_framework.decorators import action from rest_framework.response import Response from myapp.serializers import UserSerializer, PasswordSerializer class UserViewSet(viewsets.ModelViewSet): """ A viewset that provides the standard actions """ queryset = User.objects.all() serializer_class = UserSerializer @action(detail=True, methods=['post']) def set_password(self, request, pk=None): user = self.get_object() serializer = PasswordSerializer(data=request.data) if serializer.is_valid(): user.set_password(serializer.validated_data['password']) user.save() return Response({'status': 'password set'}) else: return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST) @action(detail=False) def recent_users(self, request): recent_users = User.objects.all().order_by('-last_login') page = self.paginate_queryset(recent_users) if page is not None: serializer = self.get_serializer(page, many=True) return self.get_paginated_response(serializer.data) serializer = self.get_serializer(recent_users, many=True) return Response(serializer.data) The action decorator will route GET requests by default, but may also accept other HTTP methods by setting the methods argument. For example: @action(detail=True, methods=['post', 'delete']) def unset_password(self, request, pk=None): ... Argument methods also supports HTTP methods defined as HTTPMethod. Example below is identical to the one above: from http import HTTPMethod @action(detail=True, methods=[HTTPMethod.POST, HTTPMethod.DELETE]) def unset_password(self, request, pk=None): ... The decorator allows you to override any viewset-level configuration such as permission_classes, serializer_class, filter_backends...: @action(detail=True, methods=['post'], permission_classes=[IsAdminOrIsSelf]) def set_password(self, request, pk=None): ... The two new actions will then be available at the urls ^users/{pk}/set_password/$ and ^users/{pk}/unset_password/$. Use the url_path and url_name parameters to change the URL segment and the reverse URL name of the action. To view all extra actions, call the .get_extra_actions() method. Routing additional HTTP methods for extra actions Extra actions can map additional HTTP methods to separate ViewSet methods. For example, the above password set/unset methods could be consolidated into a single route. Note that additional mappings do not accept arguments. @action(detail=True, methods=["put"], name="Change Password") def password(self, request, pk=None): """Update the user's password.""" ... @password.mapping.delete def delete_password(self, request, pk=None): """Delete the user's password.""" ... Reversing action URLs If you need to get the URL of an action, use the .reverse_action() method. This is a convenience wrapper for reverse(), automatically passing the view's request object and prepending the url_name with the .basename attribute. Note that the basename is provided by the router during ViewSet registration. If you are not using a router, then you must provide the basename argument to the .as_view() method. Using the example from the previous section: >>> view.reverse_action("set-password", args=["1"]) 'http://localhost:8000/api/users/1/set_password' Alternatively, you can use the url_name attribute set by the @action decorator. >>> view.reverse_action(view.set_password.url_name, args=['1']) 'http://localhost:8000/api/users/1/set_password' The url_name argument for .reverse_action() should match the same argument to the @action decorator. Additionally, this method can be used to reverse the default actions, such as list and create

      Let's break down the concepts in simpler terms with examples:

      Binding ViewSet to Separate Views

      In Django REST Framework, you can bind a ViewSet to separate views if needed, but it's not common. Instead, you usually register the ViewSet with a router to generate URL patterns automatically.

      Example:

      ```python from myapp.views import UserViewSet

      Binding ViewSet to separate views

      user_list = UserViewSet.as_view({'get': 'list'}) user_detail = UserViewSet.as_view({'get': 'retrieve'})

      Typically, we use a router instead

      from rest_framework.routers import DefaultRouter

      router = DefaultRouter() router.register(r'users', UserViewSet, basename='user') urlpatterns = router.urls ```

      Using Base ViewSet Classes

      Instead of writing custom ViewSets, you can use base classes like ModelViewSet that provide default behavior.

      Example:

      ```python from rest_framework import viewsets from myapp.serializers import UserSerializer from django.contrib.auth.models import User

      class UserViewSet(viewsets.ModelViewSet): """ A viewset for viewing and editing user instances. """ serializer_class = UserSerializer queryset = User.objects.all() ```

      Advantages of Using ViewSets

      1. Combined Logic: Repeated logic can be combined into a single class. For example, you only specify the queryset once, and it applies to all actions (list, retrieve, create, etc.).
      2. Automatic URL Generation: Using routers means you don't have to manually wire up URL patterns.

      Default ViewSet Actions

      Default routers provide routes for standard actions like create, retrieve, update, and destroy.

      Example:

      ```python from rest_framework import viewsets

      class UserViewSet(viewsets.ViewSet): """ Example empty viewset demonstrating the standard actions that will be handled by a router class. """

      def list(self, request):
          pass  # List all users
      
      def create(self, request):
          pass  # Create a new user
      
      def retrieve(self, request, pk=None):
          pass  # Retrieve a specific user
      
      def update(self, request, pk=None):
          pass  # Update a specific user
      
      def partial_update(self, request, pk=None):
          pass  # Partially update a specific user
      
      def destroy(self, request, pk=None):
          pass  # Delete a specific user
      

      ```

      Customizing ViewSet Actions

      You can inspect attributes during dispatch to adjust behavior based on the current action.

      Example:

      python def get_permissions(self): """ Instantiates and returns the list of permissions that this view requires. """ if self.action == 'list': permission_classes = [IsAuthenticated] else: permission_classes = [IsAdminUser] return [permission() for permission in permission_classes]

      Marking Extra Actions for Routing

      You can add custom methods that should be routable using the @action decorator.

      Example:

      ```python from rest_framework.decorators import action from rest_framework.response import Response from rest_framework import status

      class UserViewSet(viewsets.ModelViewSet): """ A viewset that provides the standard actions """ queryset = User.objects.all() serializer_class = UserSerializer

      @action(detail=True, methods=['post'])
      def set_password(self, request, pk=None):
          user = self.get_object()
          serializer = PasswordSerializer(data=request.data)
          if serializer.is_valid():
              user.set_password(serializer.validated_data['password'])
              user.save()
              return Response({'status': 'password set'})
          else:
              return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)
      
      @action(detail=False)
      def recent_users(self, request):
          recent_users = User.objects.all().order_by('-last_login')
          page = self.paginate_queryset(recent_users)
          if page is not None:
              serializer = self.get_serializer(page, many=True)
              return self.get_paginated_response(serializer.data)
      
          serializer = self.get_serializer(recent_users, many=True)
          return Response(serializer.data)
      

      ```

      Routing Additional HTTP Methods for Extra Actions

      You can map additional HTTP methods to separate ViewSet methods.

      Example:

      ```python @action(detail=True, methods=['put'], name="Change Password") def password(self, request, pk=None): """Update the user's password.""" ...

      @password.mapping.delete def delete_password(self, request, pk=None): """Delete the user's password.""" ... ```

      Reversing Action URLs

      To get the URL of an action, use the .reverse_action() method.

      Example:

      ```python

      view.reverse_action("set-password", args=["1"]) 'http://localhost:8000/api/users/1/set_password' ```

      Summary

      • ViewSets: Combine related views into a single class.
      • Routers: Automatically generate URL patterns.
      • Base Classes: Use ModelViewSet for common behavior.
      • Custom Actions: Add custom routes with the @action decorator.

      These tools help simplify and streamline API development in Django REST Framework.

    3. ViewSets After routing has determined which controller to use for a request, your controller is responsible for making sense of the request and producing the appropriate output. — Ruby on Rails Documentation Django REST framework allows you to combine the logic for a set of related views in a single class, called a ViewSet. In other frameworks you may also find conceptually similar implementations named something like 'Resources' or 'Controllers'. A ViewSet class is simply a type of class-based View, that does not provide any method handlers such as .get() or .post(), and instead provides actions such as .list() and .create(). The method handlers for a ViewSet are only bound to the corresponding actions at the point of finalizing the view, using the .as_view() method. Typically, rather than explicitly registering the views in a viewset in the urlconf, you'll register the viewset with a router class, that automatically determines the urlconf for you. Example Let's define a simple viewset that can be used to list or retrieve all the users in the system. from django.contrib.auth.models import User from django.shortcuts import get_object_or_404 from myapps.serializers import UserSerializer from rest_framework import viewsets from rest_framework.response import Response class UserViewSet(viewsets.ViewSet): """ A simple ViewSet for listing or retrieving users. """ def list(self, request): queryset = User.objects.all() serializer = UserSerializer(queryset, many=True) return Response(serializer.data) def retrieve(self, request, pk=None): queryset = User.objects.all() user = get_object_or_404(queryset, pk=pk) serializer = UserSerializer(user) return Response(serializer.data)

      Sure, let's break down the concept of ViewSets in Django REST Framework into simpler terms with examples.

      What is a ViewSet?

      In Django REST Framework, a ViewSet is a way to combine the logic for a set of related views into a single class. Instead of writing separate classes or functions for handling different HTTP methods like GET, POST, PUT, DELETE, etc., you can define these in one class.

      How ViewSets Work

      1. ViewSet Class: A ViewSet is a type of class-based view. Unlike regular class-based views where you define methods like .get() or .post(), ViewSets use actions like .list() and .create().

      2. Router: Instead of manually adding each URL for these views, you can use a router that automatically generates the URL patterns for the ViewSet.

      Example

      Let's say we want to create a simple API to list all users or get details of a specific user.

      Step 1: Create a Serializer

      First, we need a serializer to convert our User model to JSON format.

      ```python

      myapps/serializers.py

      from django.contrib.auth.models import User from rest_framework import serializers

      class UserSerializer(serializers.ModelSerializer): class Meta: model = User fields = ['id', 'username', 'email'] ```

      Step 2: Define the ViewSet

      Next, we define a ViewSet that handles listing users and retrieving a specific user.

      ```python

      views.py

      from django.contrib.auth.models import User from django.shortcuts import get_object_or_404 from myapps.serializers import UserSerializer from rest_framework import viewsets from rest_framework.response import Response

      class UserViewSet(viewsets.ViewSet): """ A simple ViewSet for listing or retrieving users. """ def list(self, request): queryset = User.objects.all() serializer = UserSerializer(queryset, many=True) return Response(serializer.data)

      def retrieve(self, request, pk=None):
          queryset = User.objects.all()
          user = get_object_or_404(queryset, pk=pk)
          serializer = UserSerializer(user)
          return Response(serializer.data)
      

      ```

      • list(): This method handles GET requests to list all users. It fetches all users from the database, serializes them, and returns the JSON response.
      • retrieve(): This method handles GET requests to get details of a specific user based on the primary key (pk).

      Step 3: Register the ViewSet with a Router

      Finally, we use a router to generate the URL patterns for our ViewSet.

      ```python

      urls.py

      from django.urls import path, include from rest_framework.routers import DefaultRouter from .views import UserViewSet

      router = DefaultRouter() router.register(r'users', UserViewSet, basename='user')

      urlpatterns = [ path('', include(router.urls)), ] ```

      Summary

      • ViewSet: A class that groups related views (e.g., list and retrieve) into a single class.
      • Actions: Methods like .list() and .retrieve() that handle specific actions.
      • Router: Automatically generates URL patterns for the ViewSet.

      Using ViewSets and routers simplifies the code and makes it easier to manage related views.

    1. eLife assessment

      Manzano et al. offer a valuable first analysis of proteins within tunneling nanotubes (TNTs), membranous bridges connecting cells. This work distinguishes TNTs from extracellular vesicles, but further experimental and analytical tools are needed to refine the TNT proteome. Solid data supports a role for tetraspanins CD9 and CD81 in TNT function. The proposed model for CD9 and CD81 is over-interpreted and requires additional evidence for stronger support.

    2. Reviewer #1 (Public Review):

      Summary:

      The authors' claims that CD9 and CD81 are key regulators of TNT formation and function are well-supported by the data. The use of KO and OE models provides strong evidence. The differential proteomic analysis between TNTs and EVPs and the functional assays justify the conclusion that these tetraspanins are critical for TNT biogenesis and functionality. Overall, the manuscript presents a nice study that advances our understanding of TNTs and their regulation by CD9 and CD81. Despite some limitations, the strengths of the experimental design and the robustness of the data justify the authors' conclusions. Future studies addressing the identified weaknesses would further solidify these findings and their implications in pathological contexts.

      Strengths:

      Novelty and Significance - this study addresses the composition and regulation of tunneling nanotubes (TNTs). By identifying the roles of CD9 and CD81 tetraspanins, the researchers offer insights into the molecular mechanisms underlying TNT formation. This could have implications for understanding cellular communication in pathological conditions such as cancer.

      Methodological Accuracy - the authors employed a well-designed biochemical approach to isolate TNTs from U2OS cells, distinguishing them from extracellular vesicles and particles (EVPs). The use of multiple independent preparations and the application of LC-MS/MS for proteomic analysis ensure robustness and reproducibility of the data.

      Complete Analysis - the study provides a detailed proteomic profile of TNTs, identifying 1177 proteins and highlighting key components. The comparative analysis between TNTs and EVPs further strengthens the findings by demonstrating distinct proteomic landscapes.

      Functional Insights - using knockout (KO) and overexpression (OE) models, the authors convincingly demonstrate the distinct roles of CD9 and CD81 in TNT formation and function. CD9 is shown to stabilize TNTs, while CD81 facilitates vesicle transfer, likely by aiding membrane docking or fusion.

      Experimental Design - the use of actin chromobody-GFP and various fluorescent markers enabled the authors to visualize TNTs and validate their isolation protocol. Additionally, the combination of electron microscopy, flow cytometry, and live-cell imaging provided convincing evidence for their claims.

      Weaknesses:

      Potential Contaminations - while the authors took steps to minimize contamination with other cellular structures, the presence of some nuclear proteins and the possible inclusion of small portions of cell bodies or ER in the TNT preparations cannot be entirely ruled out. This may affect the interpretation of some proteomic data.

      Limited Cell Models - the experiments were conducted in U2OS and SH-SY5Y cells. While these are relevant models, in vivo validation of the findings would significantly enhance the impact and translational potential of the research.

      Functional Mechanisms - although the study provides strong evidence for the roles of CD9 and CD81, the exact molecular mechanisms by which these tetraspanins regulate TNT formation and vesicle transfer remain partially speculative. Further biochemical and biophysical analyses would be necessary to elucidate these mechanisms in detail.

    3. Reviewer #2 (Public Review):

      Tunneling nanotubes (TNT) are common cellular protrusions that allow the transfer of multiple types of cargo between mammalian cells. TNTs are fragile, and lack any known unique marker, making it challenging to isolate and study them. Therefore, the content of TNTs is mostly unknown, and there are only a handful of proteins known to play a role in TNT formation or function.

      In this paper, the authors developed a new protocol to isolate TNT fragments from a culture of adherent mammalian cells in a way that is distinctive of extracellular vesicle and identify the proteins within the TNT (referred to as TNTome) by mass spectrometry. The authors provide an analysis of the results in comparison to the extracellular vesicle (EV) proteome, and validate a few examples, thus providing valuable data for the TNT field. However, there is a big overlap between TNTome and EV proteome.

      The authors further focus on two proteins, CD9 and CD81, that are enriched in TNTs. Using cells that are knocked out (KO) or over-expressing (OE) these proteins, the authors study their role in TNT formation and function. The authors focus on two major parameters, which are the percent of cells connected by TNT, and the percent of acceptor cells containing fluorescently labeled transferred vesicles. The authors use various assays, which are properly controlled, to measure these parameters. Their analysis provides convincing evidence that CD9 plays a partial role in TNT formation or stabilization and CD81 plays a partial role in forming fully elongated/connected TNT.

      However, the authors overstate the importance of these proteins, since their absence only partially affects TNT formation and function, similar to what is seen when knocking out most any other protein implicated in TNT formation. Even their best results show just a 50% reduction for TNT formation and 70% vesicle transfer (in the double KO). Thus, these are not "key" regulators as the title suggests - no more than many other factors, some of them identified by the authors in previous publications. The model presented in Figure 7D is thus misleading, as it states that CD9 KO has "No TNT" which is incorrect (only a slight decrease according to Figure 3C), and states that CD81 KO has "Non-functional TNT" whereas there is still 50% vesicle transfer in this mutant.

      In addition, the authors use vesicle transfer as a measure of function, but this is just one type of cargo amongst many others: ions, proteins, RNA, various organelles, and pathogens like viruses and bacteria. Since the authors clearly cannot test every type of cargo, the authors should at least be more accurate in their statements regarding functionality and mention the possibility that other types of cargo transfer could be less or more affected by the KO or OE of these proteins.

      It is not completely clear from the text why the authors decided to focus on CD9 and CD81, which are also found in EV, instead of focusing on TNT-unique proteins, and in particular the cytoskeleton-related ones.

      In summary, it is a good paper, that provides valuable data on the composition of TNT, and the role of additional players, bringing us closer to understanding the mechanism of TNT formation.

    4. Reviewer #3 (Public Review):

      Initially, the authors isolated TNTs from EVPs and cell bodies of cultured U2OS cells. Using transmission electronic microscopy and nanoflow cytometry, they demonstrated that these two structures are morphologically different. In engineered cells, they observed the presence of actin and CD9 in TNTs by immunofluorescence. Then they employed mass spectrometry techniques to analyze the EVPs and TNT fractions, discovering that their compositions significantly differ and that CD9 and CD81 are abundant in both structures.

      Subsequently, they studied the role of CD9 and CD81 in the formation of TNTs by using SH-SY5Y cells, first confirming their presence in TNTs via immunofluorescence. CD9 knockout (KO) cells, but not CD81 KO, exhibited a reduced percentage of cells connected via TNTs. The percentage of TNT-connected double KO cells was even lower compared to CD9 KO cells. Additionally, CD9 overexpression (OE), but not CD81 OE increased the percentage of TNT-connected cells.

      The authors then investigated the influence of CD9 and CD81 on the capacity of cells to transport material through TNTs by quantifying vesicle delivery between cells. The percentage of acceptor cells containing vesicles (I call it here the efficiency of vesicle transfer) was reduced in CD9 KO cells and CD81 KO cells, and even lower in double KO cells. CD9 OE or CD81 OE increased vesicle transfer efficiency.

      Then, they studied possible redundant or complementary roles in the formation of TNTs through a combination of KO and OE of CD9 and CD81 and observed that CD81 does not play any role in TNT formation when CD9 is present, and vesicle transfer of CD81 KO cells can be efficient in CD9 OE conditions.

      Incubation of WT cells and CD81 KO cells with an anti-CD9 monoclonal antibody caused CD9 and CD81 clustering, significantly increasing the percentage of TNT-connected cells and duration of TNTs. While the antibody enhanced vesicle transfer efficiency in WT cells, it did not affect vesicle transfer in CD81 KO cells.

      The article is well-written and addresses an important biological question, providing some insightful results. However, I have concerns regarding the connection between the experimental data and some of the conclusions drawn by the authors. Below I summarize my points:

      - The protocol used to separate TNTs from EVPs and the cell body to determine their protein composition appears problematic. The authors apply mechanical stress by vigorously shaking the samples to achieve this separation. I am skeptical that this method robustly isolates TNTs from other cellular structures/components. I am concerned that their proteomic analysis might not be analyzing the composition of TNTs exclusively, but rather a mixture that includes other structures. For example, the second and eighth most abundant proteins identified are histones (Table S1), and about 20% of the total TNT proteins identified are either mitochondrial or nuclear proteins. The authors should attempt to improve the proteomics section of their study. To differentiate structural TNT proteins from debris, the authors could use statistical analysis to compare multiple independent preparations. Structural TNT proteins will likely be consistently present across all preparations, while non-structural TNT proteins may not. If this approach proves ineffective, the authors might need to refine their TNT isolation procedure.

      - Throughout the whole manuscript, the authors quantify the percentage of cells connected by TNTs but do not provide data on the total number of TNTs, which would offer additional valuable information not captured by the percentage of TNT-connected cells alone.

      - To study TNT functionality, the authors quantified the efficiency of vesicle transfer by calculating the percentage of acceptor cells containing donor vesicles. How was this percentage computed? The actual number of vesicles delivered to acceptor cells would provide a more accurate metric of vesicle transfer efficiency.

      - In Figure 7D, the authors provide a working model. They claim that CD9 KO cells are incapable of forming TNTs. However, this is not supported by their data. The percentage of TNT-connected cells in CD9 KO cells is only slightly lower than in WT cells (Figure 3C).

      - In the abstract and discussion of Figure 7D, the authors also claim that CD81 is necessary for the functional transfer of vesicles through TNTs by regulating membrane docking/fusion with the opposing cell. Furthermore, they propose in the discussion section that CD81 is involved in the opening of the TNT. However, all these claims are purely speculative and not supported by their data. If CD81 played such a role, vesicles would accumulate at the tip of the TNTs, which does not appear to be the case. Vesicle transfer occurs in CD81 KO cells. Additionally, TNT formation and efficient vesicle transfer are observed in CD81 KO cells and CD9 OE conditions, suggesting that docking/fusion is not dependent on CD81. Can the authors justify their claims? It is possible that CD81 KO cells might form TNTs with smaller diameters, potentially hindering vesicle transfer. Quantifying the dependence of TNT diameter on CD81 and CD9 expression would address this hypothesis.

      - The authors should explain the implications of their study. They need to elaborate on how their findings could impact our understanding of cellular communication and potential applications in therapeutic strategies.

      - Tetraspanins are involved in cell migration. In the CRISPR knockout experiments, could the observed changes in the percentage of TNT-connected cells be attributed to variations in cell migration potential?

      - The reason behind the clustering of CD9 and CD81 after CD9 antibody treatment should be discussed.

    1. eLife assessment

      This work aimed at deconstructing how sebaceous gland differentiation is controlled in adult skin. Using monoclonal antibodies designed to inhibit specific Notch ligands or receptors, the authors present solid evidence that the Jag2/Notch1 signaling axis is a crucial regulator of sebocyte progenitor proliferation and sebocyte differentiation. The valuable findings presented here contribute to the growing evidence that Notch signaling not only plays a role during the development of the skin and its appendages but also regulates cell fate in adult homeostatic tissues. From a translational perspective, it is intriguing that the effect of Jag2 or Notch1 inhibition, which leads to the accumulation of proliferative stem/progenitor cells in the sebaceous gland and prevents sebocyte differentiation, is reversible.

    2. Reviewer #1 (Public Review):

      Summary:

      In this study, Abidi and colleagues used Notch pathway-neutralizing antibodies to inhibit sebaceous glands in the skin. The authors find that blocking either the Notch1 receptor or the Jag2 ligand caused loss of the glands and increased retention of sebaceous progenitor cells. Moreover, these glands began to reappear 14 days after treatment.

      Strengths:

      Overall, this study definitively identifies the Notch receptor/ligand combination that maintains these glands in the adult. The manuscript is clearly written and the figures are beautifully made.

      Weaknesses:

      Minor text edits should be made.

    3. Reviewer #2 (Public Review):

      Summary:

      In this report Abidi et al. use an antibody against Jag2, a Notch1 ligand, to inhibit its activity in skin. A single dose of this treatment leads to an impairment of sebocyte differentiation and an accumulation of basal sebocytes. Consistently Notch1 activity, measured as cleaved form of the Notch1 intracellular domain, is detected in basal sebocytes together with the expression of Jag2. Interestingly the phenotype caused by the antibody treatment is reversible.

      Strengths:

      The quality of the histological data with a clear phenotype, together with the quantification represents a solid base for the authors' claims.

      This work identifies that the ligand Jag2 is the Notch1 ligand required for sebocyte differentiation.

      From a therapeutic point of view, it is interesting that the treatment with anti-Jag2 is reversible.

      Weaknesses:

      The authors use a single approach to support their claims.

      In this report, the analysis of the potential anti-Jag2 effect on the sebaceous ducts, the second cellular component of the sebaceous gland, is neglected.

    4. Reviewer #3 (Public Review):

      Abidi et al. investigated the role of Notch signalling for sebaceous gland differentiation and sebocyte progenitor proliferation in adult mouse skin. By injecting antagonising antibodies against different Notch receptors and ligands into mice, the authors identified that the Notch1 receptor and, to a lesser extent, Notch2 receptor, as well as the Notch ligand Jagged2, contribute to the regulation of sebaceous gland differentiation. In-situ hybridisation confirmed that treatment with anti-Jagged2 dramatically reduced the number of basal sebocytes staining for the transcriptionally active intracellular domain of Notch1. Loss of Notch activity in sebocyte progenitors robustly inhibited sebaceous gland differentiation. Under these conditions, the number of sebocyte progenitors marked by Lrig1 was not affected, while the number of proliferating basal sebocytes was increased. Upon recovery of Notch activity, sebaceous gland differentiation could likewise be recovered. By suggesting that Notch activity in sebocyte progenitors is required to balance proliferation and differentiation, these data bring valuable new and relevant findings for the skin field on the sebaceous gland homeostasis.

      The data generally support the conclusions drawn by the authors; however, several additional experiments are required, and some aspects of the data analysis need to be clarified and improved to strengthen the manuscript.

    1. eLife assessment

      This valuable work presents an interesting strategy to interfere with the HBV infectious cycle as it identifies two previously unexplored HBc-Ag binding pockets. The experimental data is solid; however, the cryo-EM data is not properly explained, the structural and mechanistic details could be explained in greater detail, and the conclusions need to be supported by evaluating the effect of these molecules on viral infectivity.

    2. Reviewer #1 (Public Review):

      Summary:

      In this paper, the authors present an interesting strategy to interfere with the HBV life cycle: the preparation of geranyl and peptides' dimers that could impede the correct assembly of hepatitis B core protein HBc into viable capsids. These dimers are of different nature, depending on the HBc site the authors plan to target. A preliminary study with geranyl dimers (targeting a hydrophobic site of HBc) was first investigated. The second series deals with peptide-PEG linker-peptide dimers, targeting the tips of HBc dimer spikes.

      Strengths:

      This work is very well conducted, combining ITC experiments (for determination of dimers' KD), cellular effects (thanks to the grafting of previously developed dimers with polyarginine-based cell penetrating peptide) HBV infected HEK293 cells and Cryo-EM studies.

      The findings of these research teams unambiguously demonstrated the interest of such dimeric structures in impeding the correct HBV life cycle and thus, could bring solutions in the control of its development. Ultimately, a new class of HBV Capside Assembly Modulators could arise from this study.

      There is no doubt that this work could bring very interesting information for people working on VHB.

      Weaknesses:

      Some minor corrections must be made, especially for a more precise description of the strategy and the chemical structure of the designed new VHB capsid assembly modulators.

    3. Reviewer #2 (Public Review):

      Summary:

      Vladimir Khayenko et al. discovered two novel binding pockets on HBc with in vitro binding and electron microscopy experiments. While the geranyl dimer targeting a central hydrophobic pocket displayed a micromolar affinity, the P1-dimer binding to the spike tip of HBc has a nanomolar affinity. In the turbidity assay and at the cellular level, an HBc aggregation from peptide crosslinking was demonstrated.

      Strengths:

      The study identifies two previously unexplored binding pockets on HBc capsids and develops novel binders targeting these sites with promising affinities.

      Weaknesses:

      While the in vitro and cellular HBc aggregation effects are demonstrated, the antiviral potential against HBV infection is not directly evaluated in this study.

    4. Reviewer #3 (Public Review):

      Summary:

      HBV is a continuing public health problem and new therapeutics would be of great value. Khayenko et al examine two sites in the HBc dimer as possible targets for new therapeutics. Older drugs that target HBc bind at a pocket between two HBc dimers. In this study Khayenko et al examine sites located in the four helix bundle at the dimer interface.

      The first site is a pocket first identified as a triton100 binding site. The authors suggest it might bind terpenes and use geraniol as an example. They also test a decyl maltose detergent and a geraniol dimer intended for bivalent binding. The KDs were all in the 100µM range. Cryo-EM shows that geraniol binds the targeted site.

      The second site is at the tip of the spike. Peptides based on a 1995 study (reference 43) were investigated. The authors test a core peptide, two longer peptides, and a dimer of the longest peptide. A deep scan of the longest monomer sequence shows the importance of a core amino acid sequence. The dimeric peptide (P1-dimer) binds almost 100 fold better than the monomer parent (P1). Cryo-EM structures confirm the binding site. The dimeric peptide caused HBc capsid aggregation When HBc expressing cells were treated with active peptide attached to a cell penetrating peptide, the peptide caused aggregation of HBc antigen mirroring experiments with purified proteins.

      Strengths:

      The two sites have not been well investigated. This paper marks a start. The small collection of substrates investigated led to discovery of a dimeric peptide that leads to capsid aggregation, presumably by non-covalent crosslinking. The structures determined could be very useful for future investigations.

      Weaknesses:

      In this draft, the rational for targets for the triton x100 site is not well laid out. The target molecules bind with KDs weaker that 50µM. The way the structural results are displayed, one cannot be sure of the important features of binding site with respect to the the substrate. The peptide site and substrates are better developed, but structural and mechanistic details need to be described in greater detail.

    1. eLife assessment

      This study provides valuable insights into how the EBH domain of EB1 interacts with SxIP peptides derived from MACF. A convincing description of the thermodynamic and kinetic modes of peptide binding is provided via a combination of solution NMR techniques and ITC. Although consistent with the data, the proposed "dock-and lock" model was not found to be directly supported by evidence. This work will be of interest to structural biologists and biophysicists interested in microtubule cytoskeleton.

    2. Reviewer #1 (Public Review):

      Summary:

      In this article, Almeida and colleagues use a combination of NMR and ITC to study the interaction of the EBH domain of microtubule end-binding protein 1 (EB1) with SxIP peptides derived from the MACF plus-end tracking protein. EBH forms a dimer and in isolation has previously been shown to have a disordered C-terminal tail. Here, the authors use NMR to determine a solution structure of the EBH dimer bound to 11-mer SxIP peptides derived from MACF, and observe that the disordered C-terminal of EBH is recruited by residues C-terminal to the SxIP motif to fold into the final complex. By comparison of binding in different length peptides, and of EBH lacking the C-terminal tail, they show that these additional contacts increase binding affinity by an order of magnitude, greatly stabilising the interaction, in a binding mode they term 'dock-and-lock'.

      The authors also use their new structural knowledge to design peptides with higher affinities and show in a cell model that these can be weakly recruited to microtubule ends - although a dimeric construct is necessary for efficient recruitment. Ultimately, by demonstrating the feasibility of targeting these proteins, this work points towards the possibility of designing small-molecules to block the interactions.

      Strengths:

      The authors determine an NMR structure of the dimeric complex, and additional report nuclear spin relaxation measurements to explore conformational dynamics within the complex via S2 order parameters and exchange contributions to relaxation (Rex terms).

      A variety of appropriate experimental techniques are applied to probe the thermodynamics and kinetics of peptide binding: ITC, 2D NMR lineshape analysis, and chemical exchange saturation transfer (CEST) NMR. These yield consistent results, and a thoughtful analysis is described, based on the non-observation of exchange broadening in 2D titration and CEST measurements, in order to conclude that the proposed locking step, in which the C-terminal tail of EBH folds against the bound peptide, must occur on a rapid (sub-ms) timescale.

      The use of 2D NMR lineshape analysis enables authors to extract the fullest information from their titration data, permitting an analysis of binding kinetics in addition to affinities. They also mention briefly that this enables them to account for the fact that binding occurs to two symmetric sites on the EBH dimer.

      The authors use a range of peptide lengths, and mutations of EBH, to explore the contribution of different parts of the sequence to the overall binding affinity. They also use their structural observations to design a new peptide that binds with sub-micromolar affinity. They develop a simple but effective fluorescence assay to test the interaction of these peptides with microtubule ends within cells and show that their designed peptide can compete with native ligands for EBH.

      Weaknesses:

      There is no direct experimental evidence for independent dock and lock steps. The model is certainly plausible given their structural data, but all titration and CEST measurements are fully consistent with a simple one-step binding mechanism. Indeed, it is acknowledged that the results for the VLL peptide are not consistent with the predictions of this model, as affinity and dissociation rates do not co-vary. The model may still be a helpful way to interpret and discuss their results, and may indeed be the correct mechanism, but this has not yet been proven.

      There is little discussion of the fact that binding occurs to EBH dimers - either in terms of the functional significance of this or in the acquisition and analysis of their data. There is no discussion of cooperation in binding (or its absence), either in the analysis of NMR titrations or in ITC measurements. Complete ITC fit results have not been reported so it is not possible to evaluate this for oneself.

      Three peptides are used to examine the role of C-terminal residues in SxIP motifs: 4-MACF (SKIP), 6-MACF (SKIPTP), and 11-MACF (KPSKIPTPQRK). The 11-mer demonstrates the strongest binding, but this has added residues to the N-terminal as well. It has also introduced charges at both termini, further complicating the interpretation of changes in binding affinities. Given this, I do not believe the authors can reasonably attribute increased affinities solely to post-SxIP residues.

      Experimental uncertainties are, with exceptions, not reported.

    3. Reviewer #2 (Public Review):

      Barsukov and his colleagues investigate the interaction mechanism between the EB1 C-terminal domain (EBH) and its binding motif, "SxIP," from MACF. From the crystal structure of the C-terminus of EB1 and SxIP, it has been postulated that complex formation is a simple protein-peptide interaction, achieved by only four residues. The authors demonstrate that the post-SxIP region is involved in EBH interactions using NMR and ITC, and propose that a more complex system exists - a two-step "dock-and-lock" model. The CEST data clearly show that EBH possesses two structural conformations and that the C-terminal EBH conformation undergoes a change upon binding to 11MACF. The authors then mutate the 11MACF peptide sequence and identify peptides with much higher affinities for EBH. These findings may contribute to the development of peptide drugs targeting EB1/microtubules.

      This work provides a novel structural insight into EB1 and its binding proteins, and the authors present solid experimental evidence to support the idea. One thing the authors should do is, I think, to use the longer EB1 construct. As the authors describe in the Introduction, each domain of EB1 has a distinct function. The C-terminal tail of EB1, which is adjacent to EBH and is not analyzed in this study, is highly acidic and plays an important role in protein interactions. If the authors discuss the C-terminus of EB1, they should analyze the whole C-terminus of EB1, which would strengthen the conclusion they have made.

    1. Reviewer #1 (Public Review):

      Summary:

      The manuscript by Velichko et al. argues that the ability of nucleolar protein Treacles to form phase-separated condensates is necessary for its function in nucleolar organization, rRNA transcription, and rDNA repair. These findings may be of interest to the communities studying biomolecular condensates, nucleolar organization, and ribosome biogenesis. The authors propose that Treacle's ability to undergo liquid-liquid phase separation is the key to its role as a scaffold for the FC of the nucleolus. The experiments in this study were designed and performed well, particularly the overexpression studies, done in the absence of endogenous protein and accounted for the protein expression levels. However, in my view, the interpretation of these data should consider the possibility that specific protein-protein interactions of Treacle may also play a role in the organization of the FC compartment in vivo. The in vivo results do not exclude, and sometimes imply the presence of specific protein-protein interactions that may drive the organization of FC instead of, or in addition to LLPS.

      Main points:

      In the first part of the manuscript, the depletion of Treacle disrupted the FC and its (somewhat arbitrary) boundary with the dense fibrillar component, as well as rRNA biogenesis. The phenotypic effects of Treacle depletion by gene knockout or siRNA knockdown were evaluated thoroughly, and I see no issues here except that all experiments were conducted in HeLa cells, and it may not hurt to validate some key findings in a more normal cell line.

      Next, the authors tested the hypothesis that the function of Treacle is due to its ability to form biomolecular condensates. In vitro, recombinant Treacle displayed classical phase separation behavior, forming liquid droplets at low salt concentrations and in the presence of dextran. Similarly, overexpression of fluorescently tagged Treacle at high concentrations showed classical liquid droplet behavior, characterized by round shapes and rapid fusion, which is illustrated by beautiful live cell video microscopy. The issue I see here is with the interpretation: the formation of classical phase-separated droplets at high concentrations suggests that Treacle may require reaching a certain saturating concentration to undergo phase separation. In other words, high levels of overexpressed protein might lead to abnormal phase separation that may not happen under normal expression levels. Based on these results, it is not necessarily correct to assume that its normal conformation is solely due to phase separation, as the formation of condensates at saturating concentrations does not automatically imply that the same components undergo phase separation under physiological conditions.

      Treacle had been previously reported to interact with other proteins, specifically RPA194 and UBF, and these interactions were mapped to specific domains: the central repeated domain reportedly binds to RNA Pol I, while the C-terminus is involved in rDNA promoter recognition and UBF recruitment. Both of these proteins are necessary for rRNA transcription and nucleolar formation. Authors showed that overexpressing mutants impaired in phase separation resulted in defects in ribosomal RNA transcription and processing, as well as reduced DNA damage response efficiency. Specific protein-protein interactions as potential drivers of compartmentalization should be factored into the interpretation of these results. For instance, the deletion of the C-terminal (Δ1121-1488) results may indicate that the interaction with UBF is important. A charge-scrambled central domain mutant may have lost its interaction with Pol I. These specific interactions may establish the architecture of the compartment and increase the local concentration of Treacle, which in turn could facilitate phase separation locally. LLPS and specific protein-protein interactions are not mutually exclusive.

      Overall, the data supports the idea that the overexpressed Treacle behaves like a classic phase-separated protein, but it is still possible that at physiological levels its specific interactions with other proteins are also important for the organization of FC. I am not suggesting that authors performed a conceptually different work, but this aspect should be discussed in the manuscript.

      Other points:

      FACS - sorting used throughout the study to separate treatment from the control essentially distinguishes transfected vs untransfected cells. Since the transfection itself can have odd effects, it might be beneficial to include an additional control involving Cas9 transfection with a non-targeting guide RNA.

      The authors convincingly demonstrated in Figure 1 that the depletion of Treacle reduces RPA194 occupancy on the rDNA. This raises a question: which Treacle mutants can restore RPA194 occupancy, and which cannot?

      Figure 2 - measuring FRAP recovery rates as indicative of LLPS, at least for the full-length Treacle, would be more informative if authors assessed the protein turnover within the compartment (half or partial FRAP) versus exchange in and out of the compartment (full compartment FRAP).

      Statement related to Figure 2: "Fluorescence recovery in FCs, nucleolar caps, and extranucleolar condensates never reached the initial values over the analyzed time periods. This suggests that the high molecular exchange rate occurs through the mixing of Treacle molecules within the condensate boundaries and does not involve external diffusion". Assuming the post-bleach data were normalized to the cell's total fluorescent intensity, the presence of a substantial immobile fraction could also suggest high-affinity binding of that fraction to something within the compartment.

      Data related to DDR activation in ribosomal genes under genotoxic stress (Figure 5) is convincing, but it would not hurt to confirm the key findings in a more normal cell line, since HeLa cells may not accurately represent all aspects of healthy DDR.

    2. Reviewer #2 (Public Review):

      Summary:

      Velichko, Artem, et al. investigate the role played by the long intrinsically disordered protein Trecle in nucleolar morphology and function, with an interest in its potential ability to undergo liquid-liquid phase separation. The authors explore Treacle's role in core functions of the nucleolus (rRNA biogenesis and DNA repair), which has been a subject of continual investigation since it was identified that truncation of Treacle is the major genetic cause of Treacher-Collins syndrome. They show that knock out of Treacle leads to de-mixing of canonical markers of the FC (UBF, RPA194) and DFC (FBL) phases of the nucleolus. They also show that replacing Treacle with mutants that disrupt its bulk dynamics leads to the de-mixing of FBL. These mutants either remove the central region of Treacle (∆83-1121) or, more subtly, reduce the segregation of charged residues by scrambling them (CS- Charge Scrambled). The observed morphological disruptions mirrored disruptions to the production of rRNA and the ability to recruit the DNA-damage response factor TOPBP1. These data give new insight into the role played by the central region of Treacle in affecting its bulk dynamics and the potential effects of disruptions therein to nucleolar morphology and function.

      Strengths:

      The characterizations of changes to nuclear morphology upon Treacle knockout is the major strength of this study (Figure 1). Methodologically the CRISPR knockout appears sound. The characterized effects on the canonical markers of the FC and DFC phases support the idea that Treacle has a scaffolding function. While the effect of Treacle perturbations has been studied before, this has often been phenotyped in the context of development or rRNA biogenesis, and less often on the sub-cellular level.

      The other major strength of this study is its characterization of the effects of the charge scramble mutant. The authors find that replacing endogenous Treacle with this mutant reduces the bulk dynamics of Treacle (Figure 3K-M), de-mixes FBL from the DFC (Figure 4C-D), lowers pre-rRNA synthesis (Figure 4E-G), and abolishes the recruitment of the DNA-damage response factor TOPBP1 (Figure 5).

      Weaknesses:

      Clarity around the reagents used and deeper analyses would bolster the author's claims about the condensation behavior of Treacle.

      Limited characterization and sparse methodological details regarding recombinant Treacle lead to a concern about the observation that Treacle condenses in vitro. The concerns are offset by the fact that most of the paper uses cellular data to draw conclusions.

      The authors ascribe liquid-like behavior to Treacle based on spherical morphology and fusion events of Treacle-Katushka2S condensates as well as fluorescence recovery after a photobleaching (FRAP); these are accepted characterizations in the biomedical field. Nonetheless, the authors only use FRAP to characterize mutants, which limits conclusions about their apparent material state. Overall, FRAP data are better interpreted as a readout of bulk dynamics. For example, the FRAP traces of Treacle plateau at a recovery percentage between 40 and 60%, indicating complex bulk dynamics and the possibility of an immobile pool that is not liquid-like.

      Lastly, the Treacle-Katushka2S construct is the predominant construct used throughout the paper. The known tetrameric nature of Katushka2S contrasts with the presumptively monomeric Treacle-FusionRed-Cry2 construct. This is relevant because multi-valance is known to increase the driving forces for condensation and affect condensate material properties. The authors report that the Treacle-FusionRed-Cry2 construct (monomeric) exhibits less condensation than the Treacle-Katushka2S construct (tetrameric). Thus, one is left concerned that the latter construct is not wholly representative of intrinsic Treacle condensation behavior.

    3. Reviewer #3 (Public Review):

      Summary:

      This study provides evidence that the protein Treacle plays an essential role in the structure and function of the fibrillar center (FC) of the nucleolus, which is surrounded by the dense fibrillar component (DFC) and the granular component (GC). The authors provide new evidence that, like the DFC and GC, the functional FC compartment involves a biomolecular condensate that contains Treacle as a key component. Treacle is essential to the transcription of the rDNA as well as proper rRNA processing that the authors tie to a role in maintaining the separation of FC components from the DFC. In vitro and in vivo experiments highlight that Treacle is itself capable of undergoing condensation in a manner that depends on concentration and charge-charge interactions but is not affected by 1,6 hexanediol, which disrupts weak hydrophobic interactions. Attempting to generate separation-of-function mutants, the authors provide further evidence of complex interactions that drive proper condensation in the FC mediated by both the central repeat (low-complexity, likely driving the condensation) and C-terminal domain (which appears to target the specificity of the condensation to the proper location). Using mutant forms of Treacle defective in condensation, the authors provide evidence that these same protein forms are also disrupted in supporting Treacle's functions in rDNA transcription and rRNA processing. Last, the authors suggest that cells lacking Treacle are defective in the DNA damage response at the rDNA in response to VP16.

      Strengths:

      In general, the data are of high quality, the experiments are well-designed and the findings are mostly carefully interpreted. The findings of the work complement prior high-impact studies of the DFC and GC that have identified constituent proteins as the lynchpins of the biomolecular condensates that organize the nucleolus into its canonical three concentric compartment structure and are therefore likely to be of broad interest. The attempts to generate separation-of-function mutants to dissect the contribution of condensation to Treacle function are ambitious and critical to demonstrating the relevance of this property to the biology of the FC. The complementarity of the methods applied to investigate the Treacle function is appropriate and the findings integrate well towards a compelling narrative.

      Weaknesses:

      Although the attempt to generate separation of function mutants of Treacle is laudable (and essential), there still remain possible alternative explanations for the observed defects in such mutants as most of the experimental approaches give rise to negative results. The DDR angle of the manuscript seems somewhat more preliminary as it is largely restricted to looking at the recruitment of DDR factors to the rDNA in response to a specific insult (VP16). It would be more compelling if the authors could investigate a more biologically relevant outcome (e.g. rDNA repeat number stability).

    1. Robotic Surgery in Chennai - Precision and Innovation in Healthcare

      Experience the future of surgery with robotic technology in Chennai. Our highly skilled surgeons undertake innovative robotic operations that provide greater precision, less invasiveness, and shorter recovery times. Rely on us for cutting-edge surgical care. For additional information, please contact us immediately!

    1. Conservative white Democrats granted African Americans legal freedom but little more.

      While African Americans were granted rights, they were very limited in freedom compared to the whites.

    1. Mixins The mixin classes provide the actions that are used to provide the basic view behavior. Note that the mixin classes provide action methods rather than defining the handler methods, such as .get() and .post(), directly. This allows for more flexible composition of behavior. The mixin classes can be imported from rest_framework.mixins. ListModelMixin Provides a .list(request, *args, **kwargs) method, that implements listing a queryset. If the queryset is populated, this returns a 200 OK response, with a serialized representation of the queryset as the body of the response. The response data may optionally be paginated. CreateModelMixin Provides a .create(request, *args, **kwargs) method, that implements creating and saving a new model instance. If an object is created this returns a 201 Created response, with a serialized representation of the object as the body of the response. If the representation contains a key named url, then the Location header of the response will be populated with that value. If the request data provided for creating the object was invalid, a 400 Bad Request response will be returned, with the error details as the body of the response. RetrieveModelMixin Provides a .retrieve(request, *args, **kwargs) method, that implements returning an existing model instance in a response. If an object can be retrieved this returns a 200 OK response, with a serialized representation of the object as the body of the response. Otherwise, it will return a 404 Not Found. UpdateModelMixin Provides a .update(request, *args, **kwargs) method, that implements updating and saving an existing model instance. Also provides a .partial_update(request, *args, **kwargs) method, which is similar to the update method, except that all fields for the update will be optional. This allows support for HTTP PATCH requests. If an object is updated this returns a 200 OK response, with a serialized representation of the object as the body of the response. If the request data provided for updating the object was invalid, a 400 Bad Request response will be returned, with the error details as the body of the response. DestroyModelMixin Provides a .destroy(request, *args, **kwargs) method, that implements deletion of an existing model instance. If an object is deleted this returns a 204 No Content response, otherwise it will return a 404 Not Found. Concrete View Classes The following classes are the concrete generic views. If you're using generic views this is normally the level you'll be working at unless you need heavily customized behavior. The view classes can be imported from rest_framework.generics. CreateAPIView Used for create-only endpoints. Provides a post method handler. Extends: GenericAPIView, CreateModelMixin ListAPIView Used for read-only endpoints to represent a collection of model instances. Provides a get method handler. Extends: GenericAPIView, ListModelMixin RetrieveAPIView Used for read-only endpoints to represent a single model instance. Provides a get method handler. Extends: GenericAPIView, RetrieveModelMixin DestroyAPIView Used for delete-only endpoints for a single model instance. Provides a delete method handler. Extends: GenericAPIView, DestroyModelMixin UpdateAPIView Used for update-only endpoints for a single model instance. Provides put and patch method handlers. Extends: GenericAPIView, UpdateModelMixin ListCreateAPIView Used for read-write endpoints to represent a collection of model instances. Provides get and post method handlers. Extends: GenericAPIView, ListModelMixin, CreateModelMixin RetrieveUpdateAPIView Used for read or update endpoints to represent a single model instance. Provides get, put and patch method handlers. Extends: GenericAPIView, RetrieveModelMixin, UpdateModelMixin RetrieveDestroyAPIView Used for read or delete endpoints to represent a single model instance. Provides get and delete method handlers. Extends: GenericAPIView, RetrieveModelMixin, DestroyModelMixin RetrieveUpdateDestroyAPIView Used for read-write-delete endpoints to represent a single model instance. Provides get, put, patch and delete method handlers. Extends: GenericAPIView, RetrieveModelMixin, UpdateModelMixin, DestroyModelMixin Customizing the generic views Often you'll want to use the existing generic views, but use some slightly customized behavior. If you find yourself reusing some bit of customized behavior in multiple places, you might want to refactor the behavior into a common class that you can then just apply to any view or viewset as needed. Creating custom mixins For example, if you need to lookup objects based on multiple fields in the URL conf, you could create a mixin class like the following: class MultipleFieldLookupMixin: """ Apply this mixin to any view or viewset to get multiple field filtering based on a `lookup_fields` attribute, instead of the default single field filtering. """ def get_object(self): queryset = self.get_queryset() # Get the base queryset queryset = self.filter_queryset(queryset) # Apply any filter backends filter = {} for field in self.lookup_fields: if self.kwargs.get(field): # Ignore empty fields. filter[field] = self.kwargs[field] obj = get_object_or_404(queryset, **filter) # Lookup the object self.check_object_permissions(self.request, obj) return obj You can then simply apply this mixin to a view or viewset anytime you need to apply the custom behavior. class RetrieveUserView(MultipleFieldLookupMixin, generics.RetrieveAPIView): queryset = User.objects.all() serializer_class = UserSerializer lookup_fields = ['account', 'username'] Using custom mixins is a good option if you have custom behavior that needs to be used. Creating custom base classes If you are using a mixin across multiple views, you can take this a step further and create your own set of base views that can then be used throughout your project. For example: class BaseRetrieveView(MultipleFieldLookupMixin, generics.RetrieveAPIView): pass class BaseRetrieveUpdateDestroyView(MultipleFieldLookupMixin, generics.RetrieveUpdateDestroyAPIView): pass Using custom base classes is a good option if you have custom behavior that consistently needs to be repeated across a large number of views throughout your project. PUT as create Prior to version 3.0 the REST framework mixins treated PUT as either an update or a create operation, depending on if the object already existed or not. Allowing PUT as create operations is problematic, as it necessarily exposes information about the existence or non-existence of objects. It's also not obvious that transparently allowing re-creating of previously deleted instances is necessarily a better default behavior than simply returning 404 responses. Both styles "PUT as 404" and "PUT as create" can be valid in different circumstances, but from version 3.0 onwards we now use 404 behavior as the default, due to it being simpler and more obvious. If you need to generic PUT-as-create behavior you may want to include something like this AllowPUTAsCreateMixin class as a mixin to your views. Third party packages The following third party packages provide additional generic view implementations. Django Rest Multiple Models Django Rest Multiple Models provides a generic view (and mixin) for sending multiple serialized models and/or querysets via a single API request. D

      Mixins in Django REST Framework: Simplified Explanation

      Mixins are small, reusable classes that provide specific behavior to a view class. They are like building blocks that you can combine to create custom views. Instead of defining the handler methods like .get() or .post() directly, mixins provide action methods which allow for more flexible composition of behaviors.

      Common Mixin Classes

      Here are some commonly used mixin classes from rest_framework.mixins:

      1. ListModelMixin
      2. Purpose: Provides the ability to list a queryset.
      3. Method: .list(request, *args, **kwargs)
      4. Example: ```python from rest_framework import generics, mixins from django.contrib.auth.models import User from myapp.serializers import UserSerializer

        class UserList(mixins.ListModelMixin, generics.GenericAPIView): queryset = User.objects.all() serializer_class = UserSerializer

         def get(self, request, *args, **kwargs):
             return self.list(request, *args, **kwargs)
        

        ```

      5. CreateModelMixin

      6. Purpose: Provides the ability to create a new model instance.
      7. Method: .create(request, *args, **kwargs)
      8. Example: ```python class UserCreate(mixins.CreateModelMixin, generics.GenericAPIView): queryset = User.objects.all() serializer_class = UserSerializer

         def post(self, request, *args, **kwargs):
             return self.create(request, *args, **kwargs)
        

        ```

      9. RetrieveModelMixin

      10. Purpose: Provides the ability to retrieve a single model instance.
      11. Method: .retrieve(request, *args, **kwargs)
      12. Example: ```python class UserDetail(mixins.RetrieveModelMixin, generics.GenericAPIView): queryset = User.objects.all() serializer_class = UserSerializer

         def get(self, request, *args, **kwargs):
             return self.retrieve(request, *args, **kwargs)
        

        ```

      13. UpdateModelMixin

      14. Purpose: Provides the ability to update an existing model instance.
      15. Methods: .update(request, *args, **kwargs), .partial_update(request, *args, **kwargs)
      16. Example: ```python class UserUpdate(mixins.UpdateModelMixin, generics.GenericAPIView): queryset = User.objects.all() serializer_class = UserSerializer

         def put(self, request, *args, **kwargs):
             return self.update(request, *args, **kwargs)
        
         def patch(self, request, *args, **kwargs):
             return self.partial_update(request, *args, **kwargs)
        

        ```

      17. DestroyModelMixin

      18. Purpose: Provides the ability to delete an existing model instance.
      19. Method: .destroy(request, *args, **kwargs)
      20. Example: ```python class UserDelete(mixins.DestroyModelMixin, generics.GenericAPIView): queryset = User.objects.all() serializer_class = UserSerializer
         def delete(self, request, *args, **kwargs):
             return self.destroy(request, *args, **kwargs)
        

        ```

      Concrete View Classes

      Concrete view classes combine generic views and mixins to provide common patterns. Here are some examples:

      1. CreateAPIView
      2. Purpose: Create-only endpoints.
      3. Usage: ```python from rest_framework import generics

        class UserCreateView(generics.CreateAPIView): queryset = User.objects.all() serializer_class = UserSerializer ```

      4. ListAPIView

      5. Purpose: Read-only endpoints for a collection of model instances.
      6. Usage: python class UserListView(generics.ListAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      7. RetrieveAPIView

      8. Purpose: Read-only endpoints for a single model instance.
      9. Usage: python class UserDetailView(generics.RetrieveAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      10. DestroyAPIView

      11. Purpose: Delete-only endpoints for a single model instance.
      12. Usage: python class UserDeleteView(generics.DestroyAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      13. UpdateAPIView

      14. Purpose: Update-only endpoints for a single model instance.
      15. Usage: python class UserUpdateView(generics.UpdateAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      16. ListCreateAPIView

      17. Purpose: Read-write endpoints for a collection of model instances.
      18. Usage: python class UserListCreateView(generics.ListCreateAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      19. RetrieveUpdateAPIView

      20. Purpose: Read or update endpoints for a single model instance.
      21. Usage: python class UserRetrieveUpdateView(generics.RetrieveUpdateAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      22. RetrieveDestroyAPIView

      23. Purpose: Read or delete endpoints for a single model instance.
      24. Usage: python class UserRetrieveDestroyView(generics.RetrieveDestroyAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      25. RetrieveUpdateDestroyAPIView

      26. Purpose: Read-write-delete endpoints for a single model instance.
      27. Usage: python class UserRetrieveUpdateDestroyView(generics.RetrieveUpdateDestroyAPIView): queryset = User.objects.all() serializer_class = UserSerializer

      Customizing Generic Views with Mixins

      You can create custom mixins to encapsulate specific behaviors and reuse them across multiple views. Here's an example of a custom mixin for looking up objects based on multiple fields:

      python class MultipleFieldLookupMixin: """ Apply this mixin to any view or viewset to get multiple field filtering based on a `lookup_fields` attribute, instead of the default single field filtering. """ def get_object(self): queryset = self.get_queryset() # Get the base queryset queryset = self.filter_queryset(queryset) # Apply any filter backends filter = {} for field in self.lookup_fields: if self.kwargs.get(field): # Ignore empty fields. filter[field] = self.kwargs[field] obj = get_object_or_404(queryset, **filter) # Lookup the object self.check_object_permissions(self.request, obj) return obj

      Using Custom Mixins

      You can use the custom mixin with any view to apply the custom behavior:

      python class RetrieveUserView(MultipleFieldLookupMixin, generics.RetrieveAPIView): queryset = User.objects.all() serializer_class = UserSerializer lookup_fields = ['account', 'username']

      Custom Base Classes

      If you frequently use a mixin across multiple views, create custom base classes:

      ```python class BaseRetrieveView(MultipleFieldLookupMixin, generics.RetrieveAPIView): pass

      class BaseRetrieveUpdateDestroyView(MultipleFieldLookupMixin, generics.RetrieveUpdateDestroyAPIView): pass ```

      This way, you can reuse the custom behavior consistently across your project.

      In summary, mixins in Django REST Framework allow you to compose views with reusable actions, making your code modular and easier to maintain. The combination of mixins and generic views helps you quickly build standard CRUD (Create, Read, Update, Delete) operations with minimal code.

    2. Generic views Django’s generic views... were developed as a shortcut for common usage patterns... They take certain common idioms and patterns found in view development and abstract them so that you can quickly write common views of data without having to repeat yourself. — Django Documentation One of the key benefits of class-based views is the way they allow you to compose bits of reusable behavior. REST framework takes advantage of this by providing a number of pre-built views that provide for commonly used patterns. The generic views provided by REST framework allow you to quickly build API views that map closely to your database models. If the generic views don't suit the needs of your API, you can drop down to using the regular APIView class, or reuse the mixins and base classes used by the generic views to compose your own set of reusable generic views. Examples Typically when using the generic views, you'll override the view, and set several class attributes. from django.contrib.auth.models import User from myapp.serializers import UserSerializer from rest_framework import generics from rest_framework.permissions import IsAdminUser class UserList(generics.ListCreateAPIView): queryset = User.objects.all() serializer_class = UserSerializer permission_classes = [IsAdminUser] For more complex cases you might also want to override various methods on the view class. For example. class UserList(generics.ListCreateAPIView): queryset = User.objects.all() serializer_class = UserSerializer permission_classes = [IsAdminUser] def list(self, request): # Note the use of `get_queryset()` instead of `self.queryset` queryset = self.get_queryset() serializer = UserSerializer(queryset, many=True) return Response(serializer.data) For very simple cases you might want to pass through any class attributes using the .as_view() method. For example, your URLconf might include something like the following entry: path('users/', ListCreateAPIView.as_view(queryset=User.objects.all(), serializer_class=UserSerializer), name='user-list') API Reference GenericAPIView This class extends REST framework's APIView class, adding commonly required behavior for standard list and detail views. Each of the concrete generic views provided is built by combining GenericAPIView, with one or more mixin classes. Attributes Basic settings: The following attributes control the basic view behavior. queryset - The queryset that should be used for returning objects from this view. Typically, you must either set this attribute, or override the get_queryset() method. If you are overriding a view method, it is important that you call get_queryset() instead of accessing this property directly, as queryset will get evaluated once, and those results will be cached for all subsequent requests. serializer_class - The serializer class that should be used for validating and deserializing input, and for serializing output. Typically, you must either set this attribute, or override the get_serializer_class() method. lookup_field - The model field that should be used for performing object lookup of individual model instances. Defaults to 'pk'. Note that when using hyperlinked APIs you'll need to ensure that both the API views and the serializer classes set the lookup fields if you need to use a custom value. lookup_url_kwarg - The URL keyword argument that should be used for object lookup. The URL conf should include a keyword argument corresponding to this value. If unset this defaults to using the same value as lookup_field. Pagination: The following attributes are used to control pagination when used with list views. pagination_class - The pagination class that should be used when paginating list results. Defaults to the same value as the DEFAULT_PAGINATION_CLASS setting, which is 'rest_framework.pagination.PageNumberPagination'. Setting pagination_class=None will disable pagination on this view. Filtering: filter_backends - A list of filter backend classes that should be used for filtering the queryset. Defaults to the same value as the DEFAULT_FILTER_BACKENDS setting. Methods Base methods: get_queryset(self) Returns the queryset that should be used for list views, and that should be used as the base for lookups in detail views. Defaults to returning the queryset specified by the queryset attribute. This method should always be used rather than accessing self.queryset directly, as self.queryset gets evaluated only once, and those results are cached for all subsequent requests. May be overridden to provide dynamic behavior, such as returning a queryset, that is specific to the user making the request. For example: def get_queryset(self): user = self.request.user return user.accounts.all() Note: If the serializer_class used in the generic view spans orm relations, leading to an n+1 problem, you could optimize your queryset in this method using select_related and prefetch_related. To get more information about n+1 problem and use cases of the mentioned methods refer to related section in django documentation. get_object(self) Returns an object instance that should be used for detail views. Defaults to using the lookup_field parameter to filter the base queryset. May be overridden to provide more complex behavior, such as object lookups based on more than one URL kwarg. For example: def get_object(self): queryset = self.get_queryset() filter = {} for field in self.multiple_lookup_fields: filter[field] = self.kwargs[field] obj = get_object_or_404(queryset, **filter) self.check_object_permissions(self.request, obj) return obj Note that if your API doesn't include any object level permissions, you may optionally exclude the self.check_object_permissions, and simply return the object from the get_object_or_404 lookup. filter_queryset(self, queryset) Given a queryset, filter it with whichever filter backends are in use, returning a new queryset. For example: def filter_queryset(self, queryset): filter_backends = [CategoryFilter] if 'geo_route' in self.request.query_params: filter_backends = [GeoRouteFilter, CategoryFilter] elif 'geo_point' in self.request.query_params: filter_backends = [GeoPointFilter, CategoryFilter] for backend in list(filter_backends): queryset = backend().filter_queryset(self.request, queryset, view=self) return queryset get_serializer_class(self) Returns the class that should be used for the serializer. Defaults to returning the serializer_class attribute. May be overridden to provide dynamic behavior, such as using different serializers for read and write operations, or providing different serializers to different types of users. For example: def get_serializer_class(self): if self.request.user.is_staff: return FullAccountSerializer return BasicAccountSerializer Save and deletion hooks: The following methods are provided by the mixin classes, and provide easy overriding of the object save or deletion behavior. perform_create(self, serializer) - Called by CreateModelMixin when saving a new object instance. perform_update(self, serializer) - Called by UpdateModelMixin when saving an existing object instance. perform_destroy(self, instance) - Called by DestroyModelMixin when deleting an object instance. These hooks are particularly useful for setting attributes that are implicit in the request, but are not part of the request data. For instance, you might set an attribute on the object based on the request user, or based on a URL keyword argument. def perform_create(self, serializer): serializer.save(user=self.request.user) These override points are also particularly useful for adding behavior that occurs before or after saving an object, such as emailing a confirmation, or logging the update. def perform_update(self, serializer): instance = serializer.save() send_email_confirmation(user=self.request.user, modified=instance) You can also use these hooks to provide additional validation, by raising a ValidationError(). This can be useful if you need some validation logic to apply at the point of database save. For example: def perform_create(self, serializer): queryset = SignupRequest.objects.filter(user=self.request.user) if queryset.exists(): raise ValidationError('You have already signed up') serializer.save(user=self.request.user) Other methods: You won't typically need to override the following methods, although you might need to call into them if you're writing custom views using GenericAPIView. get_serializer_context(self) - Returns a dictionary containing any extra context that should be supplied to the serializer. Defaults to including 'request', 'view' and 'format' keys. get_serializer(self, instance=None, data=None, many=False, partial=False) - Returns a serializer instance. get_paginated_response(self, data) - Returns a paginated style Response object. paginate_queryset(self, queryset) - Paginate a queryset if required, either returning a page object, or None if pagination is not configured for this view. filter_queryset(self, queryset) - Given a queryset, filter it with whichever filter backends are in use, returning a new queryset.

      Generic Views in Django and Django REST Framework: Simplified Explanation

      What are Generic Views?

      Django's Generic Views: - Purpose: Generic views in Django are pre-built views designed to handle common patterns and tasks. Instead of writing repetitive code for common functionalities, you can use these views to save time. - Example: If you want to create a view to list all users or create a new user, instead of writing the code from scratch, you can use a generic view that already handles these tasks.

      Django REST Framework's (DRF) Generic Views: - Purpose: Similar to Django's generic views, DRF provides generic views for building API endpoints quickly and efficiently. These views map closely to your database models. - Example: If you need an API endpoint to list all users or create a new user via an API call, DRF's generic views can do this with minimal code.

      Benefits of Using Generic Views

      • Code Reusability: Generic views abstract common patterns, reducing the need to write repetitive code.
      • Simplicity: Makes it easy to set up views for standard operations like listing, creating, updating, or deleting records.
      • Customization: You can easily customize these views by setting class attributes or overriding methods.

      Basic Example of Using Generic Views

      Here’s a simple example of how to use a generic view in Django REST Framework to create a list and create user API:

      ```python from django.contrib.auth.models import User from myapp.serializers import UserSerializer from rest_framework import generics from rest_framework.permissions import IsAdminUser

      class UserList(generics.ListCreateAPIView): queryset = User.objects.all() # The queryset of all User objects serializer_class = UserSerializer # The serializer to use for input/output permission_classes = [IsAdminUser] # Only allow admin users to access this view ```

      Overriding Methods for Custom Behavior

      You can customize the behavior of these views by overriding methods. For example, to customize the list method:

      ```python class UserList(generics.ListCreateAPIView): queryset = User.objects.all() serializer_class = UserSerializer permission_classes = [IsAdminUser]

      def list(self, request):
          queryset = self.get_queryset()  # Use get_queryset() to get the data
          serializer = UserSerializer(queryset, many=True)
          return Response(serializer.data)
      

      ```

      Using Generic Views in URL Configuration

      You can directly use the generic view in your URL configuration:

      ```python from django.urls import path from rest_framework.generics import ListCreateAPIView from django.contrib.auth.models import User from myapp.serializers import UserSerializer

      urlpatterns = [ path('users/', ListCreateAPIView.as_view(queryset=User.objects.all(), serializer_class=UserSerializer), name='user-list') ] ```

      Important Attributes and Methods in GenericAPIView

      • queryset: The set of data that the view will operate on.
      • serializer_class: The class used to serialize and deserialize data.
      • lookup_field: The field used to look up individual model instances (default is 'pk').
      • pagination_class: The class used for paginating results.
      • filter_backends: List of classes used to filter the queryset.

      Common Methods:

      • get_queryset(self): Returns the queryset to use for the view.
      • get_object(self): Returns a single object instance for detail views.
      • filter_queryset(self, queryset): Filters the queryset based on the filter backends.

      Example of Customizing get_queryset

      If you want to customize the queryset based on the user making the request:

      python def get_queryset(self): user = self.request.user return user.accounts.all()

      In summary, Django and Django REST Framework's generic views provide a powerful and efficient way to handle common view patterns, making development faster and more maintainable. You can use, customize, and extend these views to suit the specific needs of your application.

    1. 処理実行

      処理が実行

    2. 辞書は情報の断片の間の関連を格納します

      「情報の断片の間の関連」が読みにくいと感じた。 代案 辞書は要素間の関連情報を格納します。

    1. RRID:SCR_008520

      DOI: 10.1136/jitc-2024-009410

      Resource: FlowJo (RRID:SCR_008520)

      Curator: @evieth

      SciCrunch record: RRID:SCR_008520


      What is this?

    2. RRID:SCR_002798

      DOI: 10.1136/jitc-2024-009410

      Resource: GraphPad Prism (RRID:SCR_002798)

      Curator: @evieth

      SciCrunch record: RRID:SCR_002798


      What is this?

    3. RRID:CVCL_A700

      DOI: 10.1136/jitc-2024-009410

      Resource: CVCL_A700

      Curator: @evieth

      SciCrunch record: RRID:CVCL_A700


      What is this?

    4. RRID:CVCL_0526

      DOI: 10.1136/jitc-2024-009410

      Resource: (ATCC Cat# HTB-72, RRID:CVCL_0526)

      Curator: @evieth

      SciCrunch record: RRID:CVCL_0526


      What is this?

    1. RRID:AB_2733817

      DOI: 10.1084/jem.20232167

      Resource: AB_2733817

      Curator: @evieth

      SciCrunch record: RRID:AB_2733817


      What is this?

    2. RRID:AB_397037

      DOI: 10.1084/jem.20232167

      Resource: (BD Biosciences Cat# 558116, RRID:AB_397037)

      Curator: @evieth

      SciCrunch record: RRID:AB_397037


      What is this?

    1. mCherry

      DOI: 10.1093/g3journal/jkae057

      Resource: (BDSC Cat# 35785,RRID:BDSC_35785)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_35785


      What is this?

    2. Su(var)3–9

      DOI: 10.1093/g3journal/jkae057

      Resource: RRID:BDSC_6210

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_6210


      What is this?

    3. yellow (y)

      DOI: 10.1093/g3journal/jkae057

      Resource: (BDSC Cat# 64527,RRID:BDSC_64527)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_64527


      What is this?

    4. Su(var)3-7

      DOI: 10.1093/g3journal/jkae057

      Resource: RRID:BDSC_64598

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_64598


      What is this?

    5. Dcr-2

      DOI: 10.1093/g3journal/jkae057

      Resource: BDSC_33656

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_33656


      What is this?

    6. Rm62

      DOI: 10.1093/g3journal/jkae057

      Resource: RRID:BDSC_31395

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_31395


      What is this?

    7. (Dcr-1

      DOI: 10.1093/g3journal/jkae057

      Resource: BDSC_28598

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_28598


      What is this?

    8. msl2

      DOI: 10.1093/g3journal/jkae057

      Resource: RRID:BDSC_31627

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_31627


      What is this?

    9. CLAMP

      DOI: 10.1093/g3journal/jkae057

      Resource: BDSC_57163

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_57163


      What is this?

    10. Rluc

      DOI: 10.1093/g3journal/jkae057

      Resource: (BDSC Cat# 64774,RRID:BDSC_64774)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_64774


      What is this?

    11. PBac{y[ + ]-attP-3B}VK00033 (65B2)

      DOI: 10.1093/g3journal/jkae057

      Resource: (BDSC Cat# 9750,RRID:BDSC_9750)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_9750


      What is this?

    1. P{TRiP.GL00151}attP2

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    2. P{TRiP.GL00236}attP2

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    3. P{TRiP.{"type":"entrez-protein","attrs":{"text":"GLV21065","term_id":"2687838985","term_text":"GLV21065"}}GLV21065}attP2

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    4. BubR1-GFP/ Bwinscy

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    5. P{wrdGL00671wdbHMS01864}/TM3

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    6. P{TRiP. HMS00409}

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    7. P{w+mC=UA Sp-Spc 105R}

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    8. P{TRiP.GL00625}attP40

      DOI: 10.1101/2024.03.14.585003

      Resource: BDSC_37482

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_37482


      What is this?

    9. P{TRiP.GL00392}attP2

      DOI: 10.1101/2024.03.14.585003

      Resource: BDSC_35466

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_35466


      What is this?

    10. Bloomington Drosophila Stock Center

      DOI: 10.1101/2024.03.14.585003

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    1. 42735

      DOI: 10.1242/dev.202388

      Resource: (BDSC Cat# 42735,RRID:BDSC_42735)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_42735


      What is this?

    2. 5580

      DOI: 10.1242/dev.202388

      Resource: (BDSC Cat# 5580,RRID:BDSC_5580)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_5580


      What is this?

    3. (8603)

      DOI: 10.1242/dev.202388

      Resource: (BDSC Cat# 8603,RRID:BDSC_8603)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_8603


      What is this?

    4. (10546)

      DOI: 10.1242/dev.202388

      Resource: (BDSC Cat# 10546,RRID:BDSC_10546)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_10546


      What is this?

    5. Bloomington Drosophila Stock Center

      DOI: 10.1242/dev.202388

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    1. RRID:AB_2904198

      DOI: 10.7554/eLife.98649

      Resource: (Abcam Cat# ab179503, RRID:AB_2904198)

      Curator: @dhovakimyan1

      SciCrunch record: RRID:AB_2904198


      What is this?

    2. RRID:AB_299021

      DOI: 10.7554/eLife.98649

      Resource: AB_299021

      Curator: @dhovakimyan1

      SciCrunch record: RRID:AB_299021


      What is this?

    3. RRID:AB_945626

      DOI: 10.7554/eLife.98649

      Resource: (Abcam Cat# ab56416, RRID:AB_945626)

      Curator: @dhovakimyan1

      SciCrunch record: RRID:AB_945626


      What is this?

    4. Addgene plasmid 41393

      DOI: 10.7554/eLife.98649

      Resource: RRID:Addgene_41393

      Curator: @dhovakimyan1

      SciCrunch record: RRID:Addgene_41393


      What is this?

    1. GMR-Gal4 (#8121)

      DOI: 10.1038/s41598-024-65172-4

      Resource: (BDSC Cat# 8121,RRID:BDSC_8121)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_8121


      What is this?

    2. elav-Gal4 (#458)

      DOI: 10.1038/s41598-024-65172-4

      Resource: (BDSC Cat# 458,RRID:BDSC_458)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_458


      What is this?

    1. BDSC, 93186

      DOI: 10.1371/journal.pbio.3002549

      Resource: BDSC_93186

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_93186


      What is this?

    2. BDSC, 94405

      DOI: 10.1371/journal.pbio.3002549

      Resource: BDSC_94405

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_94405


      What is this?

    3. Bloomington Stock Center

      DOI: 10.1371/journal.pbio.3002549

      Resource: Bloomington Drosophila Stock Center (RRID:SCR_006457)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:SCR_006457


      What is this?

    1. AddGene 12260

      DOI: 10.1016/j.atherosclerosis.2024.118531

      Resource: RRID:Addgene_12260

      Curator: @vtello

      SciCrunch record: RRID:Addgene_12260


      What is this?

    2. AddGene 8454

      DOI: 10.1016/j.atherosclerosis.2024.118531

      Resource: RRID:Addgene_8454

      Curator: @vtello

      SciCrunch record: RRID:Addgene_8454


      What is this?

    3. HEK293

      DOI: 10.1016/j.atherosclerosis.2024.118531

      Resource: (IZSLER Cat# BS CL 129, RRID:CVCL_0045)

      Curator: @vtello

      SciCrunch record: RRID:CVCL_0045


      What is this?

    4. stock number 002052) mice were purchased from Jackson Laboratory

      DOI: 10.1016/j.atherosclerosis.2024.118531

      Resource: (IMSR Cat# JAX_002052,RRID:IMSR_JAX:002052)

      Curator: @vtello

      SciCrunch record: RRID:IMSR_JAX:002052


      What is this?

    1. Stock #9147

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 9147,RRID:BDSC_9147)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_9147


      What is this?

    2. Stock #34814

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 34814,RRID:BDSC_34814)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_34814


      What is this?

    3. Stock #33644

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 33644,RRID:BDSC_33644)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_33644


      What is this?

    4. Stock #57492

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 57492,RRID:BDSC_57492)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_57492


      What is this?

    5. Stock #35578

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 35578,RRID:BDSC_35578)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_35578


      What is this?

    6. Stock #34639

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 34639,RRID:BDSC_34639)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_34639


      What is this?

    7. Stock #33951

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 33951,RRID:BDSC_33951)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_33951


      What is this?

    8. Stock #4937

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 4937,RRID:BDSC_4937)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_4937


      What is this?

    9. Stock #4775

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 4775,RRID:BDSC_4775)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_4775


      What is this?

    10. Stock #1495

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 1495,RRID:BDSC_1495)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_1495


      What is this?

    11. Stock #7108

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 7108,RRID:BDSC_7108)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_7108


      What is this?

    12. Stock #7018

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 7018,RRID:BDSC_7018)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_7018


      What is this?

    13. Stock #4442

      DOI: 10.1371/journal.pone.0300337

      Resource: (BDSC Cat# 4442,RRID:BDSC_4442)

      Curator: @DavidDeutsch

      SciCrunch record: RRID:BDSC_4442


      What is this?

    1. BDSC#7013

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 7013,RRID:BDSC_7013)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_7013


      What is this?

    2. BDSC#25783

      DOI: 10.1038/s41467-024-46698-7

      Resource: RRID:BDSC_25783

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_25783


      What is this?

    3. BDSC#33951

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 33951,RRID:BDSC_33951)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_33951


      What is this?

    4. BDSC#9674

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 9674,RRID:BDSC_9674)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_9674


      What is this?

    5. BDSC#25752

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 25752,RRID:BDSC_25752)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_25752


      What is this?

    6. BDSC#25754

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 25754,RRID:BDSC_25754)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_25754


      What is this?

    7. BDSC#36537

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 36537,RRID:BDSC_36537)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_36537


      What is this?

    8. BDSC#31041

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 31041,RRID:BDSC_31041)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_31041


      What is this?

    9. BDSC#8263

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 8263,RRID:BDSC_8263)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_8263


      What is this?

    10. BDSC#8253

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 8253,RRID:BDSC_8253)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_8253


      What is this?

    11. BDSC#31540

      DOI: 10.1038/s41467-024-46698-7

      Resource: (BDSC Cat# 31540,RRID:BDSC_31540)

      Curator: @anisehay

      SciCrunch record: RRID:BDSC_31540


      What is this?

    1. BDSC_67662

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 67662,RRID:BDSC_67662)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_67662


      What is this?

    2. BDSC_37749

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 37749,RRID:BDSC_37749)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_37749


      What is this?

    3. BDSC_24621

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 24621,RRID:BDSC_24621)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_24621


      What is this?

    4. BDSC_24492

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 24492,RRID:BDSC_24492)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_24492


      What is this?

    5. BDSC_31603

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 31603,RRID:BDSC_31603)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_31603


      What is this?

    6. BDSC_51635

      DOI: 10.26508/lsa.202402853

      Resource: (BDSC Cat# 51635,RRID:BDSC_51635)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_51635


      What is this?

    1. UAS-Timp (#BL58707)

      DOI: 10.7554/eLife.94748

      Resource: BDSC_58707

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_58707


      What is this?

    2. D. melanogaster Canton-S (#BL64349)

      DOI: 10.7554/eLife.94748

      Resource: (BDSC Cat# 64349,RRID:BDSC_64349)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_64349


      What is this?

    1. tub-gal80ts (BL-7017)

      DOI: 10.1371/journal.pone.0305696

      Resource: (BDSC Cat# 7017,RRID:BDSC_7017)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_7017


      What is this?

    2. UAS-dSmad2-RNAi (BL-41670)

      DOI: 10.1371/journal.pone.0305696

      Resource: (BDSC Cat# 41670,RRID:BDSC_41670)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_41670


      What is this?

    3. R31H09-gal4 (BL-49694)

      DOI: 10.1371/journal.pone.0305696

      Resource: BDSC_49694

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_49694


      What is this?

    4. daughterless (da)-gal4 (BL-55850)

      DOI: 10.1371/journal.pone.0305696

      Resource: (BDSC Cat# 55850,RRID:BDSC_55850)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_55850


      What is this?

    1. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 68139,RRID:BDSC_68139)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_68139


      What is this?

    2. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 77066,RRID:BDSC_77066)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_77066


      What is this?

    3. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 27027,RRID:BDSC_27027)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_27027


      What is this?

    4. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 41917,RRID:BDSC_41917)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_41917


      What is this?

    5. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 54461,RRID:BDSC_54461)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_54461


      What is this?

    6. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: RRID:BDSC_27249

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_27249


      What is this?

    7. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 33981,RRID:BDSC_33981)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_33981


      What is this?

    8. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 34066,RRID:BDSC_34066)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_34066


      What is this?

    9. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 32464,RRID:BDSC_32464)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_32464


      What is this?

    10. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 33379,RRID:BDSC_33379)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_33379


      What is this?

    11. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 32859,RRID:BDSC_32859)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_32859


      What is this?

    12. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 34618,RRID:BDSC_34618)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_34618


      What is this?

    13. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 33637,RRID:BDSC_33637)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_33637


      What is this?

    14. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 441,RRID:BDSC_441)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_441


      What is this?

    15. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: BDSC_59607

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_59607


      What is this?

    16. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 47618,RRID:BDSC_47618)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_47618


      What is this?

    17. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 3605,RRID:BDSC_3605)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_3605


      What is this?

    18. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 2376,RRID:BDSC_2376)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_2376


      What is this?

    19. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 59012,RRID:BDSC_59012)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_59012


      What is this?

    20. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: RRID:BDSC_76600

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_76600


      What is this?

    21. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 5137,RRID:BDSC_5137)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_5137


      What is this?

    22. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: BDSC_67072

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_67072


      What is this?

    23. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 6874,RRID:BDSC_6874)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_6874


      What is this?

    24. shows the details of the fly stocks used.

      DOI: 10.1083/jcb.202306087

      Resource: (BDSC Cat# 6409,RRID:BDSC_6409)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_6409


      What is this?

    1. G-TRACE (28281)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 28281,RRID:BDSC_28281)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_28281


      What is this?

    2. UAS-SH3PX1RNAi (27653)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_27653

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_27653


      What is this?

    3. UAS-sSpi (58436)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 58436,RRID:BDSC_58436)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_58436


      What is this?

    4. UAS-spiRNAi (28387)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_28387

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_28387


      What is this?

    5. UAS-RhoRNAi (28690)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 28690,RRID:BDSC_28690)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_28690


      What is this?

    6. UAS-RasRNAi (29319)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 29319,RRID:BDSC_29319)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_29319


      What is this?

    7. UAS-EgfrRNAi (25781)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 25781,RRID:BDSC_25781)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_25781


      What is this?

    8. TRE-DsRed (59011)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 59011,RRID:BDSC_59011)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_59011


      What is this?

    9. UAS-Alg3 (90943)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_90943

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_90943


      What is this?

    10. UAS-BskK53R (9311)

      DOI: 10.1038/s41467-024-49786-w

      Resource: (BDSC Cat# 9311,RRID:BDSC_9311)

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_9311


      What is this?

    11. UAS-Alg12RNAi (34680)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_34680

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_34680


      What is this?

    12. UAS-Alg9RNAi (65998)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_65998

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_65998


      What is this?

    13. UAS-Alg3RNAi (53350)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_53350

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_53350


      What is this?

    14. UAS-Alg2RNAi (55671)

      DOI: 10.1038/s41467-024-49786-w

      Resource: BDSC_55671

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_55671


      What is this?

    15. UAS-P35 (6298

      DOI: 10.1038/s41467-024-49786-w

      Resource: RRID:BDSC_6298

      Curator: @bandrow

      SciCrunch record: RRID:BDSC_6298


      What is this?